[ Vulkan 연구 ] 번역 : Vulkan barriers explained

주의 : 번역이 개판이므로 이상하면 원문을 참조하세요.

주의 : 허락받고 번역한 게 아니므로 언제든 내려갈 수 있습니다.

주의 : 번역이 좀 껄끄럽거나 귀찮으면 원문을 그대로 쓰겠습니다.

원문 : Vulkan barriers explained, GpuOpen.

---

벌칸( Vulkan )의 배리어( barrier ) 시스템은 독특합니다. 왜냐하면 그것은 트랜지션( transitioning )중인 리소스들을 여러분이 제공할 것을 요청할 뿐만 아니라, 소스 파이프라인 스테이지( source pipeline stage )와 타깃( target ) 파이프라인 스테이지를 지정할 것도 요구하기 때문입니다. 이는 트랜지션이 실행될 때 더욱 미세한( fine-grained ) 제어를 할 수 있도록 해 줍니다. However, you can also leave quite some performance on the table if you just use the simple way, 그래서 오늘은 vkCmdPipelineBarrier 에 대해서 자세히 알아 보도록 하겠습니다.

Pipeline Overview

GPU 는 엄청나게 파이프라인화되어 있는 디바이스라는 것은 일반적인 상식입니다. 커맨드들은 탑( top )으로 들어가며, 버텍스 셰이딩( vertex shading )이나 프래그먼트( fragment ) 셰이딩과 같은 개별 스테이지들이 순서대로 실행됩니다. 마지막으로 커맨드들은 실행이 완료될 때 파이프라인의 바텀( bottom )에서 리타이어( retire )됩니다( 역주 : 일반적으로 CPU 에서는 리타이어되었다는 의미가 out-of-order execution 에서의 실행을 종료하고 올바른 결과를 산출했다는 의미입니다. 예를 들어 branch-prediction 같은 것에 의해 취소되지 않았다는 의미입니다 ).

이런 스테이지들은 VK_PIPELINE_STAGE 열거형을 통해서 벌칸에 노출됩니다. 아래와 같이 정의되어 있습니다.

• TOP_OF_PIPE_BIT
• DRAW_INDIRECT_BIT
• VERTEX_INPUT_BIT
• VERTEX_SHADER_BIT
• TESSELLATION_CONTROL_SHADER_BIT
• TESSELLATION_EVALUATION_SHADER_BIT
• GEOMETRY_SHADER_BIT
• FRAGMENT_SHADER_BIT
• EARLY_FRAGMENT_TESTS_BIT
• LATE_FRAGMENT_TESTS_BIT
• COLOR_ATTACHMENT_OUTPUT_BIT
• TRANSFER_BIT
• COMPUTE_SHADER_BIT
• BOTTOM_OF_PIPE_BIT

이 열거형은 커맨드가 실행되는 순서와 같은 것은 아닙니다 -- 일부 스테이지들은 병합될 수도 있고 일부 스테이지들은 사라질 수도 있지만, 전체적으로 이것들은 커맨드가 통과할 파이프라인 스테이지들입니다.

세 개의 의사 스테이지( pseudo-stage )들이 존재하는데, 이것들은 다중의 스테이지들을 합치거나 특별한 접근을 제어하는데 사용됩니다:

• HOST_BIT
• ALL_GRAPHICS_BIT
• ALL_COMMANDS_BIT

이 아티클에서는 TOP_OF_PIPE_BIT 와 BOTTOM_OF_PIPE_BIT 사이의 리스트들에 대해 논의할 것입니다. 자, 배리어 문맥에서 소스와 타깃은 뭘까요? 그것들을 "생산자( producer )" 스테이지와 "소비자( consumer )" 스테이지로 생각할 수 있습니다 -- 소스 스테이지가 생산자가 되고, 타깃 스테이지가 소비자가 됩니다. 소스 및 타깃 스테이지를 지정함으로써, 드라이버에게 전이가 실행되기 전에 어떤 연산들이 완료될 필요가 있는지 그리고 어떤 연산들이 아직 시작되면 안 되는지를 알려줄 수 있습니다.

예 1: 느린 배리어, 파이프의 바텀을 소스 스테이지로 지정하고 파이프의 탑을 타깃 스테이지로 지정.

가장 단순한 경우를 살펴 봅시다. BOTTOM_OF_PIPE_BIT 를 소스 스테이지로 지정하고 TOP_OF_PIPE_BIT 를 타깃 스테이지로 지정합니다( 예 1 ). 이를 위한 소스 코드는 다음과 같습니다:

vkCmdPipelineBarrier( commandBuffer, VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT, // source stage VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT, // destination stage /* remaining parameters omitted */);

이 트랜지션은, 현재 GPU 에서 실행중( in flight )인 모든 커맨드들이 완료되고 나서 그 트랜지션이 실행되어야 하며, 트랜지션을 종료하기 전에 어떠한 커맨드들도 실행되어서는 안 된다는 것을 의미합니다. 이 배리어는 실행중인 모든 것을 종료하고 어떠한 작업도 실행되지 않도록 막기 위해서 대기할 것입니다. 그것은 일반적으로는 이상적이지 않습니다. 왜냐하면 불필요한 파이프라인 버블( bubble, 역주 : pipeline stall 을 pipeline bubble 이라 부르기도 합니다 )을 겪도록 만들기 때문입니다.

예 2: 최적의 배리어. 모든 녹색 파이프라인 스테이지들이 실행되는 것이 허용됨.

버텍스 셰이더에서 데이터를 imageSotre 를 통해서 저장하고 컴퓨트 셰이더가 그것을 소비하기를 원한다고 상상해 봅시다. 이 경우에, imageStore 를 통해 저장하는 작업이 완료될 때까지 시간이 너무 오래 걸릴 수도 있기 때문에, 프래그먼트 셰이더를 처리하지 못하고 대기해야할 수 있습니다. 여러분은 이런 상황을 원하지는 않을 겁니다. 여러분이 정말 원하는 건 버텍스 셰이더가 완료되자 마자 컴퓨트 셰이더를 시작하는 것일 겁니다. 이를 표현하는 방식은 소스 스테이지를 VERTEX_SHADER_BIT 로 설정하고 타깃 스테이지를 COMPUTE_SHADER_BIT 로 설정하는 겁니다( 예 2 ).

vkCmdPipelineBarrier( commandBuffer, VK_PIPELINE_VERTEX_SHADER_BIT, // source stage VK_PIPELINE_COMPUTE_SHADER_BIT, // destination stage /* remaining parameters omitted */);

만약 렌더 타깃을 쓰고 그것을 프래그먼트 셰이더에서 읽고자 한다면, 이 소스 스테이지는 VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT 일 것이고 타깃 스테이지는 VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT 일 겁니다. 이는 G-Buffer 렌더링에서 일반적입니다. 셰도우 맵의 경우, 소스는 VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT 가 될 겁니다. 다른 일반적인 예는 데이터 복사입니다 - 복사를 통해 데이터를 생성할 때 소스 스테이지를 VK_PIPELINE_STAGE_TRANSFER_BIT 로 설정하고 타깃 스테이지를 그것을 필요로 하는 스테이지로 설정하면 됩니다. 버텍스 버퍼에서 사용한다고 하면 이것은 VK_PIPELINE_STAGE_VERTEX_INPUT_BIT 일 겁니다.

일반적으로 여러분은 언블락킹된( unblocked ) 스테이지들의 개수를 최대화하려고 시도해야 합니다. 즉, 데이터를 빨리 생성하고 그것을 나중에 기다리는 겁니다. 생산자 측에서 파이프라인의 바텀을 향해 이동하는 것은 항상 안전합니다. 왜냐하면 더 많은 스테이지들이 끝날 때까지 대기해야 하기 때문입니다. 하지만 성능은 개선되지 않겠죠. 비슷하게 소비자 측에서 안전하기를 원한다면, 파이프라인의 위쪽인 탑으로 이동하면 됩니다 - 하지만 그것은 더 많은 스테이지들을 실행하는 것을 방해하게 될 것입니다. 그래서 그것 또한 피해야 합니다.

마지막으로 주의할 점: 앞에서 언급했듯이, 하드웨어는 내부적으로 모든 스테이지들을 가지고 있는게 아닙니다. 혹은 특정 스테이지에서는 시그널링하거나 웨이트할 수 없을 수도 있습니다. 그런 경우에는, 드라이버가 마음대로 소스 스테이지를 파이프라인의 탑이나 바텀으로 이동시키거나 타깃 스테이지를 탑으로 이동시킬 수 있습니다. 이는 구현측-명세에 따르기는 하지만 여러분이 그것에 대해서 걱정할 필요가 없습니다 - 여러분의 목적은 스테이지들은 가능한 한 짜임새있게( tight ) 설정하고 블락킹된 스테이지의 개수를 최소화하는데 있기 때문입니다.

Matthäus Chajdas is a developer technology engineer at AMD. Links to third party sites, and references to third party trademarks, are provided for convenience and illustrative purposes only. Unless explicitly stated, AMD is not responsible for the contents of such links, and no third party endorsement of AMD or any of its products is implied.