그냥 그런 블로그

원문 : https://software.intel.com/en-us/articles/adaptive-screen-space-ambient-occlusion

샘플 소스 : https://github.com/GameTechDev/ASSAO/

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

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

By Filip Strugar, published on November 9, 2016, updated Feburary 13, 2017

이 기사는 어댑티브 스크린 스페이스 앰비언트 오클루전( adaptive screen space ambient occlusion )( ASSAO )라 불리는 이펙트( effect )의 새로운 구현에 대해서 소개합니다. 그것은 저전력 디바이스에서부터 고해상도를 가진 고성능 데스크탑들까지를, 통일된 외견( look ), 설정들, 업계 표준과 동일한 품질을 가진 하나의 구현하에서, 다룰 수 있도록 특별하게 설계되었습니다. 

SSAO 는 작은 범위의 앰비언트 이펙트들과 콘택트( contact ) 셰도우( shadow ) 이펙트들을 생성하기 위해 실시간 렌더링에서 사용되는 대중적인 이펙트입니다. 많은 현대의 게임 엔진들에서 사용되고 있으며, 보통 프레임 GPU 시간의 5 ~ 10 퍼센트만큼을 사용하게 됩니다. 여러 개의 알려진 구현들이 이미 존재하기는 하지만, 그 어떤 것도 오픈 소스이거나 무료로 이용할 수 있거나 저전력 모바일로부터 데스크탑 디바이스에 이르기까지 요구되는 성능 범위 단계( level of performance scaling )를 제공하지는 않습니다. 이 부분을 ASSAO 가 만족시켜줄 수 있습니다.

이 기사는 샘플코드를 이해하고 더 나아가 그것을 통합하거나 포팅( port )하는 방법에 대해서 초점을 맞추고 있습니다. 또한 구현 명세들과 이용가능한 옵션들과 설정들, 그리고 그것을 사용하는 데 있어 발생하는 트레이드 오프( trade-off )들에 다룹니다. 구현의 세부사항에 대해서 다루는 기사는 앞으로 나올 GPU Zen( GPU Pro* 8 )에 있습니다.

그림 1. Unity 4* 의 씬에 적용된 ASSAO 의 예제.

Full DirectX* 11 implementation is provided under MIT license in an easy-to-integrate package.

Algorithm Overview

ASSO 는 확장성( scalability )와 유연성( flexibility )을 위해 튜닝( tune )된  SSAO 구현입니다. AO 구현은 입체각( solid-angle ) 오클루전 모델에 기반합니다. 이는 novel progressive sampling kernel disk 를 사용하는 [Bavoil et al. 2008] 의 "Horizon-Based Ambient Occlusion" 과 유사합니다. 그것을 둘러싼 성능 프레임워크( performance framework )는 캐시 친화적인 deinterleaved rendering 의 2 x 2 버전입니다( 역주 : 이 방식에 대해서는 [ Deinterleaved Texturing for Cache-Efficient Interleaved Sampling ] 에서 다루고 있습니다 ). 그것은 "Deinterleaved Texturing for Cache-Efficient Interleaved Sampling" [Bavoil 2014] 와 선택적 뎁스( depth ) MIP-mapping 인 "Scalable Ambient Obscurance" [McGuire et al. 2012 ] 에서 언급되었습니다.

성능 관점에서 확장성 품질은 ( 점진적인 샘플링 커널( progressive sampling kernel )에 의해 활성화된 ) 다양한 AO 탭( tap )의 개수와 다양한 프리셋 레벨에서의 개별 기능들을 토글링( toggling )함으로써 결정됩니다.

마지막에 노이즈 제거( de-noise ) 블러가 적용된 인접 픽셀들 사이의 ( 회전되고 스케일링된 샘플링 디스크에 따른 ) AO 값을 공유하기 위해서 확률적( stochastic ) 샘플링을 사용합니다. 노이즈 제거 블러는 앞이나 뒤에 있는 오브젝트들에 AO 효과가 스며들어( bleeding ) 헤일로( halo )가 발생하는 것을 막기 위해 엣지를 고려합니다( edge-aware ). 가장자리는 뎁스에만 기반하거나 뎁스와 노멀( normal )에 기반합니다( 후자는 더 좋은 품질을 생성하지만, 처리하는 데 더 많은 비용을 사용합니다 ). 이런 스마트( smart ) 블러는 최적의 캐시 효율정을 위해 2 x 2 deinterleaved 영역( domain )에서 수행됩니다. Interleaving( 재구성 ) 패스 동안에 마지막 패스에서만 전체 해상도가 사용됩니다.

경험적으로, 그것은 다중 패스 픽셀 셰이더 기반 기법입니다. High 프리셋에서의 주요 단계들은 다음과 같습니다:

1. 뎁스들을 준비합니다.
1. 2 x 2 deinterleave 입력 스크린 뎁스를 4 개의 쿼터( quarter )-뎁스 버퍼들로 만들고, 값들을 뷰스페이스( viewspace )로 변환합니다. 입력 스크린 노멀들이 제공되지 않는다면, 그것들을 뎁스로부터 재구성합니다.
2. 각각의 작은 뎁스 버퍼들을 위해 MIP 들을 생성합니다( Lowest 프리셋에서는 하지 않고, Low 프리셋이나 Medium 프리셋에서는 합니다 ).
2. AO 항과 엣지를 고려한 블러를 4 개의 2 x 2 deinterleaved 파트( part )들에 대해서 계산합니다.
1. AO 항과 엣지들을 계산하고 R8G8 텍스쳐에 저장합니다.
2. 엣지를 고려한 스마트 블러를 적용합니다( 한 패스에서 여섯 패스까지, 사용자 설정에 달려 있습니다 ).
3. 네 파트를 전체 해상도 버퍼에 합칩고 최종적으로 엣지를 고려한 블러 패스를 적용합니다.

Highest/Adaptive 품질 프리셋은 추가적인 기반( base ) AO 패스를 가지고 있으며, 이는 메인( main ) AO 패스의 픽셀당 변수 샘플 카운트를 안내( guide )하는 중요한 휴리스틱( heuristic )들을 제공하는데 사용됩니다.

표1 은 성능 수치들에 대한 개요를 제공합니다. 이 수치들은 참고용이며 드라이버와 하드웨어 명세에 따라 달라질 수 있습니다. 'radius' 같은 이펙트 설정을 변경하는 것은 성능에 영향을 주지 않습니다. 하지만 엣지를 고려한 블러의 경우에는 예외입니다; 블러 패스의 개수를 증가시키는 것은 비용을 증가시킵니다.

표1. 다양한 프리셋, 해상도, 하드웨어에서 ASSAO 이펙트 비용을 밀리세컨드( millisecond ) 단위로 표시.

스크린 노멀이 제공되고, 2-패스 블러와 Highest adaptive target 가 0.45 로 설정되면, Lowest/Low/Medium/High/Highest 프리셋들 사이의 이펙트 스케일링( 품질 vs 성능 )이 다양한 AO 탭의 개수와 개별 기능들에 대한 on/off 를 통해 결정됩니다. 표 2 는 이런 프리셋들의 세부적인 설정들을 보여 줍니다.

표 2. ASSAO 프리셋의 세부사항.

Sample Overview

샘플은 DirectX 11 을 사용하고 Windows* 7 64-bit 이상, 그리고 Microsoft Visual Studio* 2015 와 호환됩니다.

그림 2. ASSAO 샘플 레이아웃( layout ).

샘플에 포함된 Crytek Sponza* 씬이 기본으로 사용되며 기본 이펙트 프로우파일링 측정치( metric ) 이 우상단쪽 그래프에 나옵니다. 그래프 아래에는, 이펙트 설정, 품질, 혹은 이펙트 디버깅을 변경하기 위해 사용되는 여러 개의 다이얼( dial )들이 있습니다. 주요 설정은 다음과 같습니다:

1. Effect enabled
   이펙트의 on/off 를 토글합니다.
   
   
2. Effect radius
   뷰스페이스 단위의 앰비언트 오클루전의 반지름입니다.
   
   
3. Effect strength
   선형 이펙트 배율( multiplier ). 이펙트 파워( power )와 함께 이펙트의 강도를 조절하고 이펙트를 페이드( fade ) 인/아웃( in/out )하는 데 유용합니다.
   
   
4. Effect power
   지수적인( exponential ) 이펙트 수정자입니다: occlusion = pow( occlusion, effectPower ). 이펙트 커브의 파워를 변경( tweak )하는 최상의 방법입니다.
   
   
5. Detail effect strength
   고주파수( high-frequency ) 이펙트를 추가하는 데 사용하는 2 픽셀 넓은 추가 커널입니다. 높은 값을 지정하면 에일리어싱( aliasing )과 일시적인 불안정성( temporal instability )이 증가합니다.
   
   
6. Blur amount
   블러 패스의 개수를 더 높게 설정하면 더 낮은 고주파수 버전( less high-frequency variation )을 사용하는 것보다 더 부드러운 결과를 산출합니다. 이는 ( 에일리어싱을 줄여주는 ) 이점을 가지지만, 비용을 증가시킵니다.
   
   
7. Blur sharpness
   거리 기반( 그리고 선택적인 노멀 기반 ) 가장자리가 흐려지는 것을 막는 정도를 결정합니다. 다른 앞뒤의 오브젝트들 사이에서 이펙트가 번지는 것을 막는데 사용됩니다. 이펙트가 번지면 헤일로와 다른 문제들이 발생합니다. 1 값이 의미하는 것은 완전히 날카로워( 엣지에서 블러링하지 않음 )지고 제약이 완화됨을 의미합니다. 1 에 가까운 값들은 에일이어싱을 제어하는 데 유용합니다.
   
   
8. Deferred Path
   디퍼드 경로에서, 이펙트를 위한 입력들은 스크린 뎁스 텍스쳐와 노멀맵 텍스쳐입니다. 하지만, 포워드 패스가 사용되면, 뎁스 텍스쳐만이 입력으로 사용됩니다. 반면에 노멀맵은 뎁스로부터 재구성되는데, 이로 인해 비용이 추가되며 약간 다른 결과를 산출하게 됩니다.
   
   
9. Expand resolution
   스크린 가장자리 근처에서는 이펙트 커널이 스크린 밖에서 처리되는 부분이 있습니다. 다양한 샘플링 모드( 즉 clamp/mirror )들이 다양한 결과를 산출하는데 사용될 수 있지만( m_amplerStateViewspaceDepthTab ), 최적의해결방법은 뎁스 퍼버를 생성하는 동안에 일정 비율만큼 더 크게 렌더링 영역과 해상도를 확장하는 것입니다. 그래서 AO 이펙트가 사용하는 데이터가 가장자리에서도 이용될 수 있게 합니다. ASSAO 는 선택적인 시저 사각형( scissor rectangle )을 사용해서 확장된 ( 보이지 않는 ) 영역들에 대한 AO 계산이 이루어지지 않도록 합니다.
   
   
10. Texturing enabled
    AO 이펙트를 더 잘보이게 만들기 위해 ( 라이팅은 여전히 적용됨 ) 텍스쳐링을 토글합니다.
    
    
11. Quality preset
    표 1 과 2 에서 설명되어 있듯이, 네 개의 품질 프리셋 사이에서 프리셋을 교체합니다.
    Highest/Adaptive 프리셋의 경우, Adaptive 타깃은 점진적인( progressive ) 품질 타깃을 제어하는데, 이는 품질과 성능을 빠르게 교환( trade-off )하기 위해 런타임에 변경될 수 있습니다.
    
    
12. Switch to advanced UI
    이펙트를 더 자세히 디버깅하기 위해서, 샘플이 진보된 UI 로 변경되도록 할 수 있습니다. 이는 추가적인 씬들에 대한 접근을 제공하고 이펙트의 개발자 버전을 제공합니다. 이는 더 자세한 프로우파일링을 허용하며, 노멀, 검출된 가장자리, 선택된 픽셀에 대한 모든 AO 샘플들, adaptive effect heatmap 등을 보여 주는 다양한 디버그 뷰를 제공합니다.
    
    

Integration Details

DirectX 11 코드를 빠르게 통합하려면, 샘플 프로젝트에서 세 개의 파일들만 필요합니다:

• Projects\ASSAO\ASSAO\ASSAO.h
• Projects\ASSAO\ASSAO\ASSAODX11.h
• Projects\ASSAO\ASSAO\ASSAO.hlsl

DirectX 11 API 를 제외한 다른 종속성 없이 전체 ASSAO 구현들이 포함되어 있습니다.

기본적인 ASSAO 통합 단계는 다음과 같습니다:

1. ASSAO.h 와 ASSAODX11.cpp 를 프로젝트에 추가합니다.
2. ASSAO.hlsl 파일을 로드할 수 있는 곳에다가 추가하십시오. 혹은 바이너리로 .hlsl 파일을 쉽게 임베드하는 방법( 그리고 커스텀 빌드 단계에 대한 )의 세부사항을 원한다면 ASSAOWrapperDX11.cpp "USE_EMBEDDED_SHADER" 를 참조하십시오.
3. DirectX 11 디바이스 생성 후에, 정적 ASSAO_Effect::CreateInstance(...) 에다가 ID3D11Device 포인터와 셰이더 소스 버퍼를 제공함으로써, ASSAO_Effect 오브젝트 인스턴스를 생성하십시오. DirectX 디바이스가 파괴되기 전에 ASSAO_Effect::DestroyInstance() 를 호출해서 오브젝트를 파괴하는 것을 잊어 버리면 안 됩니다.
4. 포스트 프로세싱 파이프라인 안에서 적절한 위치를 찾으십시오: SSAO 는 보통 스크린 스페이스 이펙트들이 실행되기 전에 라이트 누적( accumulation ) 버퍼나 포스트-톤맵 컬러 버퍼들에 직접적으로 적용되는데, 항상 곱( multiplication ) 블렌드 모드를 사용합니다. 라이팅 패스에서 나중에 사용하기 위한 개별 버퍼에다가 AO 항을 렌더링하기 위해 종종 더욱 물리적으로 정확한 접근법이 사용됩니다. 어떤 경우든지 간에, 요청되는 입력들은 씬 뎁스( 그리고 가능하다면 스크린 스페이스 노멀 )이므로, ASSAO 는 그것들을 이용할 수 있는 시점에 그려져야 합니다.
5. 프레임당 입력 구조체를 ASSAO_InputsDX11 에서 채웁니다:
1. SissorLeft/Right/Top/Bottom 은 Expand resolution 접근법이 사용되는 경우처럼 이펙트 출력이 더 작은 사각형으로 제한될 때만 사용됩니다. 그렇지 않으면 기본값인 0 이 사용되며, 이는 전체 뷰포트로 출력이 나간다는 것을 의미합니다.
2. ViewportX/Y 는 반드시 0 이어야 하며 ViewportWidth/Height 는 입력 뎁스 텍스쳐 해상도 및 스크린 스페이스 노멀 텍스쳐 해상도와 출력 렌더 타깃의 크기여야 합니다.
3. ProjectionMatrix 는 뎁스 버퍼를 그릴 때 사용된 프로젝션이어야 합니다. 왼손 좌표계와 오른손 좌표계가 역전된 Z( reversed Z )와 함께 모두 지원됩니다( http://outerra.blogspot.de/2012/11/maximizing-depth-buffer-range-and.html )( 역주 : 역전된 Z 와 관련해서는 [ Depth Precision Visualized ] 에 번역해 둔 다른 자료도 있습니다  ).
4. NormalsWorldToViewspaceMatrix ( 선택적임 ) 는 입력 스크린 스페이스 노말이 뷰스페이스에 존재하지 않을 때 필요합니다. 이 경우에는 이 행렬이 뷰스페이스로 변환되어야 합니다.
5. MatricesRowMajorOrder 는 입력 ProjectMatrix 와 NormalsWorldtoViewspaceMatrix 의 메모리 레이아웃을 정의합니다.
6. NormalsUnpackMul 와 NormalsUnpackAdd 의 기본값은 2 와 -1 입니다. 그리고 노멀들을 일반적으로 저장되는 UNORM[0,1] 텍스쳐로부터 [-1,1] 범위로 언패킹하는데 사용됩니다. 노멀들이 부동소수점 수 텍스쳐로 제공된다면, 이 값들은 각각 1 (mul) 과 0 ( add ) 으로 설정될 필요가 있습니다.
7. DrawOpaque 는 블렌딩 모드를 지정합니다: 이 값이 true 라면 선택된 렌더 타깃의 내용이 덮어써질 것입니다; 이 값이 false 라면 multiplicative 블렌딩 모드가 사용됩니다.
8. DeviceContext ( DirectX 11 전용 ) 는 이펙트를 렌더링하는데 사용되는 ID3D11DeviceContext 포인터로 설정되어야 합니다.
9. DepthSRV ( DirectX 11 전용 ) 는 입력 뎁스 데이터로 설정되어야 합니다.
10. NormalSRV ( DirectX 11 전용 ) 는 입력 스크린 스페이스 노멀로 설정되거나 이용할 수 없다면 nullptr 로 설정되어야 합니다( 이 경우에 노멀들은 뎁스 데이터로부터 재구성됩니다 ).
11. OverrideOutputRTV ( DirectX 11 전용 ) 는 nullptr 로 설정되거나 출력 렌더 타깃으로 설정되어야 합니다. 이 값이 nullptr 로 설정되면, 현재 선택되어 있는 RTV 가 사용됩니다.
6. ASSAO_Settings 에 정의된 설정 구조체를 채웁니다. Sample overview 섹션에서 자세히 설명하고 있습니다.
7. ASSAO_Effect::Draw 함수를 호출합니다. 현재 모든 DirectX 11 스테이트( state )들은 끈임없는 통합을 보장하기 위해서 그 호출 이후에 백업되고 복구됩니다.

가장 최신의 소스 코드는 https:/github.com/GameTechDev/ASSAO 에서 다운로드할 수 있습니다.

Citations

[Bavoil et al. 2008] Bavoil, L., Sainz, M., and Dimitrov, R. 2008. "Image-Space Horizon-Based Ambient Occlusion.” In ACM SIGGRAPH 2008 talks, ACM, New York, NY, USA, SIGGRAPH ’08, 22:1–22:1.

[McGuire et al. 2012] Morgan McGuire, Michael Mara, David Luebke. “Scalable Ambient Obscurance.” HPG 2012.

[Bavoil 2014] Louis Bavoil, “Deinterleaved Texturing for Cache-Efficient Interleaved Sampling.” NVIDIA 2014.

Notices

This sample source code is released under the MIT License.

원문 : https://developer.samsung.com/game/usage

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

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

Introduction

Vulkan 용례 가이드는 독자가 이미 API 와 친숙하지만 여러 종류의 Galaxy 디바이스에서 효율적으로 사용하는 방법에 대해서 알고자 한다고 가정합니다. 또한 일반적으로 모바일 디바이스들에서 찾아볼 수 있는 타일 기반 렌더링( Tile Based Rendering, TBR ) GPU 아키텍쳐의 기초에도 익숙하다고 가정합니다. Vulkan 초심자라면 API 개념을 코드 예제와 함께 소개하는 추천 SDK 들부터 시작하실 수 있습니다. GPU 아키텍쳐에 대해서는 여기에서 학습하실 수도 있습니다.

이 문서를 읽기 전에, Game Asset Optimization Recommendations 에도 익숙해지기를 권장합니다.

Understand your target

고성능 애플리케이션을 개발할 때, 여러분이 대상으로 하는 하드웨어 및 API 의 기능( capabilities )과 성능 특성( characteristics )을 이해하는 것이 필수적입니다.

Vulkan 의 경우, 다음을 포함합니다:

• 최대 그래픽스 API 버전.
• 기능들
• 예를 들어 최대 텍스쳐 해상도.
• 확장( extension )들.

다른 성능 집중 API 와 마찬가지로, Vulkan 에는 API 사용자가 고려하지 않으면 정의되지 않는 동작을 발생시킬 수 있는 상황들이 존재합니다. 크로노스( Khronos ) Vulkan Validation Layers 와 Graphics API debugging tools 는 API 의 오용을 식별하는 데 도움을 줍니다. 또한 개발 초기 단계에 버그를 식별하기 위해 애플리케이션을 광범위한 디바이스, 칩셋( chipset ), GPU 아키텍쳐에 대해서 테스트하는 것이 매우 중요합니다.

Asset optimization

Game Asset Optimization Recommendations 을 확인하세요.

Shader Precision

SPIR-V 는 정밀도 한정자( precision qualifier )들을 지원합니다( OpDecorate RelaxedPrecision ). 정밀도 힌트( hint )는 ALU 연산들의 성능을 개선하기 위해서, 개발자가 감소된( reduced ) 정밀도를 사용할 위치를 컴파일러에게 알려줄 수 있도록 하며, 결국 GPU 의 전력 소비를 줄이게 됩니다.

변수에 대해 요청된 정밀도를 컴파일러가 받아들이는 것은 유효합니다. 예를 들어 개발자가 RelaxedPrecision 을 지정할 때는 32 비트 부동소수점 정밀도를 사용합니다. 컴파일러는 정밀도 변환을 위해 도입된 명령어가 완전한( full ) 정밀도로 계산을 실행하는 것보다 더 많은 부하를 발생시키는 경우에 이 방법을 사용하는 경향이 있습니다.

Pipeline management

파이프라인을 드로( draw ) 시점에 생성하는 것은 성능 끊김( stutter )을 유발합니다. 파이프라인을 애플리케이션을 실행할 때 가능한 한 초기에 생성하는 것을 권장합니다. 파이프라인을 드로 시점 전에 생성하도록 렌더링 엔진을 재구성하는 것이 불가능하다면, 파이프라인을 한 번만 생성하고 그것들을 맵에 넣어서 연속되는 드로 호출들에서 해싱된( hashed ) 스테이트( state )들을 통해 검색할 수 있도록 하는 것을 권장합니다.

파이프라인 캐시는 새로운 파이프라인이 생성될 때 드라이버가 캐싱된 파이프라인들로부터 스테이트들을 재사용할 수 있도록 해 줍니다. 이는 셰이더 컴파일같은 반복되는 비싼 연산들 대신에 이미 구워진 스테이트를 재사용함으로써 성능을 상당히 개선할 수 있습니다. 단일 파이프라인 캐시를 사용해서 드라이버가 이전에 생성되었던 모든 스테이트들을 재사용할 수 있도록 보장하는 것을 권장합니다. 또한 파이프라인 캐시를 파일에 써서 다음 번에 애플리케이션이 실행될 때 재사용될 수 있도록 하기를 권장합니다.

파이프라인 상속( derivative )은 애플리케이션이 "자식" 파이프라인들을 유사한 "부모" 파이프라인으로부터의 증분 스테이트 변경( incremental state changes )으로서 표현할 수 있도록 해 줍니다; 일부 아키텍쳐들에서 이는 유사한 스테이트들 간의 전환 비용을 줄여줄 수 있습니다. 많은 모바일 GPU 들은 주로 파이프라인 캐시를 통해 성능을 개선합니다. 그래서 파이프라인 상속은 종종 휴대용( portable ) 모바일 애플리케이션에 대해서는 이점을 제공하지 않습니다.

Descriptor set management

디스크립터 셋은 드로를 위한 리소스 바인딩을 정의합니다. 이상적으로 볼 때, 디스크립터 셋들은 빌드 시점에 생성되어야 하고 런타임 실행을 위해 캐싱되어야 합니다. 그것이 불가능하면, 디스크립터 셋들을 가능한 한 애플리케이션 실행 초기에 생성해야 합니다( 애플리케이션 로드나 레벨 로드 ).

Vulkan 의 대부분의 리소스들과 마찬가지로, API 사용자는 디스크립터 셋 갱신( update )을 동기화( synchronizing )할 책임이 있습니다. 그래야 대기중인 디바이스 읽기가 존재할 때 호스트에서 변경이 발생하지 않는 것이 보장됩니다. 리소스 동기화를 단순화하기 위해서 스왑 인덱스( swap index ) 별 디스크립터 풀( pool )을 사용하고 같은 바인딩을 사용하는 드로 사이에서 디스크립터 공유( sharing )를 이용( facilitate )하는 것을 권장합니다. 렌더링 엔진을 재구성하는 것이 불가능하고 드로 시점에 디스크립터 셋을 갱신할 필요가 있다면, 사용중인( in-flight ) 디스크립터를 변경하는 것을 피하기 위해, 디스크립터 셋과 버퍼를 관리하는 전략이 매우 주의깊게 고려되어야 합니다. 아래의 Buffer management 에서도 기술하듯이, 엔진이 최소 VkPhysicsDeviceLimits::maxUniformBufferRange 값에 대처하도록 하는 것이 중요합니다. 왜냐햐면 디스크립터들 사이에서 버퍼를 공유할 때 그 제한을 쉽게 초과할 수 있기 때문입니다.

유니폼( uniform ) 버퍼나 스토리지( storage ) 버퍼의 옵셋( offset )이 자주 변경된다면( 예를 들어 드로 때마다 ), VK_DESCRIPTOR_TYPE_*_BUFFER_DYNAMIC 을 사용해 버퍼를 동적으로 바인딩하고 vkCmdBindDescriptorSets() 가 호출될 때 옵셋을 pDynamicOffsets 로 설정하는 것을 권장합니다. 이는 그 옵셋들이 드로 실행 전에 디스크립터 셋을 수정하지 않고 변경될 수 있도록 해 줍니다.

Buffer management

Game Asset Optimizations: Interleaved vertex attributes 에서 기술했듯이, position 애트리뷰트들은 다른 애트리뷰트들과는 다른 버퍼에 저장되어야 합니다. 이는 현대 모바일 GPU 들이 버텍스( vertex ) 셰이딩을 더 효율적으로 실행할 수 있게 해 줍니다. 서로 다른 빈도로 업데이트를 하지 않는 한에는, 다른 모든 애트리뷰트들은 단일 버퍼에 삽입되어야 합니다.

유니폼 버퍼들은 애플리케이션 실행시에 가능한 한 초기에 할당되어야 하며, 프레임 당 할당은 피해야 합니다( 이전의 할당을 재사용하는 것이 훨씬 빠릅니다 ). 실행중인 렌더러들이 현재 프레임의 API 호출에 의해 변경되는 버퍼 영역에 접근하는 것을 끝마치도록 보장하기 위해 펜스( fence )를 사용해야 합니다.

유니폼 버퍼는 서로 다른 빈도로 업데이트되는 데이터를 포함해서는 안 됩니다. 예를 들어, 드로가 정적인 데이터와 프레임 당 설정되는 데이터( 예를 들어 변환 행렬 )에 의존한다면, 두 개의 버퍼가 사용되어야 합니다. 다중 드로에 대해 공유되는 유니폼 데이터는 단일 버퍼에 저장되어야 합니다.

중복 전송( redundant transfer )들을 막기 위해서, 유니폼 데이터 메모리는 VK_MEMORY_PEROPERTY_HOST_VISIBLE_BIT 셋으로 할당되어야 합니다. 이 플래그는 vkMapMemory() 가 호스트로부터 효율적인 수정을 위해 사용될 수 있도록 합니다( 스테이징( staging) 버퍼에 비하면 복사 한 번이 더 적습니다 ). 잦은 Map/Unmap 호출은 피해야 합니다. 가능하다면 버퍼는 VkMemoryProeprtyFlagBits::VK_MEMORY_PROPERTY_HOST_COHERENT_BIT 를 설정함으로써 영구적으로 매핑될 수 있습니다. 주의 : 영구적인 매핑은 API 캡쳐 도구들이 버퍼 수정을 트래킹하는 것을 더 어렵게 만듭니다. 이러한 이유로, 전용 GPU 메모리를 사용하는 플랫폼( platform )을 위해 영구적으로 매핑되지 않는 대안( non-persistently mapped fallback ) 경로를 구현하여 디버깅을 단순화하는 것을 권장합니다.

버퍼는 VkPhysicalDeviceLimits::min*Alignment 제한으로 정렬( align )되어야 합니다. 디스크립터 셋 바인딩과 버퍼 할당의 최대 크기는 다음과 같이 질의될 수 있습니다:

Descriptor set management 에서 기술했듯이, 디스크립터 셋 갱신을 최소화하기 위해서 동적 버퍼들과 동적 옵셋들을 사용해야 합니다.

셰이더 입력의 경우에는 항상 스토리지 버퍼보다는 유니폼 버퍼를 선호( prefer )해야 합니다.

Shader inputs

Vulkan 은 셰이더 상수들을 설정하기 위한 다양한 메커니즘을 제공합니다; 유니폼 버퍼, 특수화( specialization ) 상수, 푸시( push ) 상수.

특수화 상수들은 정적인 값들인데, 파이프라인 생성 시점에 설정될 수 있습니다( SPIR-V 바이너리가 컴파일될 때 ).

푸시 상수들은 버퍼 오브젝트가 아니라 Vulkan 커맨드를 통해서 셰이더 상수 입력 데이터를 설정하기 위한 메커니즘을 제공합니다. 푸시 상수 저장 공간은 제한적입니다. 푸시 상수 저장소를 위한 최대 바이트 수는 VkPhysicalDeviceLimits::maxPushConstantsSize 를 사용해 질의될 수 있습니다. 가능하다면 동적 유니폼 퍼버 옵셋과 같은 특수화 옵셋 메커니즘을 푸시 상수보다는 더 선호해야 합니다. 렌더링 엔진이 모든 드로들을 푸시 상수 데이터( 128 바이트 )를 위해 최소 maxPushConstantsSize 바이트 미만으로 사용하는 것을 보장할 수가 없다면, 유니폼 버퍼 기반 대안을 구현해 둘 필요가 있습니다. 이는 가장 작은 크기의 푸시 상수 바이트만을 지원하는 Vulkan 구현에서 렌더링 엔진이 작동하는 것을 보장합니다. 동적 유니폼 버퍼 옵셋을 사용하는 경우, vkCmdBindDescriptorSets() 를 호출해 드로 당 옵셋을 설정할 수 있습니다.

아래 목록들은 셰이더에서 상수값을 설정하는 것과 관련한 권장 사향들을 정리한 것입니다:

• 정적 브랜칭( static branching ): SPIR-V 생성 시점에 실행 경로들을 지정할 수 있다면, 실행 경로를 위해 전용 SPIR-V 를 생성하십시오( 예를 들어 GLSL 의 #define 을 사용 ). 그렇지 않으면, SPIR-V 파이프라인 생성 시점에 특수화 상수를 사용하십시오.
• 파이프라인 생성 시점 상수들: 파이프라인 생성 시점에 상수값을 설정할 수 있다면, 특수화 상수들을 사용하십시오.
• 유니폼 버퍼에 대한 잦은 갱신들: vkCmdBindDescriptorSets() 호출 후에 유니폼 데이터 갱신이 여러 드로들에 적용되면, 동적 유니폼 버퍼를 사용하고 vkCmdBindDescriptorSet() 이 호출될 때 동적 옵셋들을 사용하십시오. 그래야 디스크립터 셋에 대한 변경을 피할 수 있습니다( 자세한 내용을 알고자 한다면 Descriptor set management 섹션을 참조하세요 ). 유니폼 데이터가 자주 갱신된다면, 예를 들어 드로마다 갱신된다면, 동적 유니폼 버퍼 옵셋 대신에 푸시 상수를 사용하는 것을 고려해 보십시오.

Beware: No Implicit uniform type conversions

OpenGL ES 와는 다르게, Vulkan 은 묵시적으로 유니폼 타입 변환을 수행하지 않습니다. 개발자들은 버퍼 바인딩의 내용이 그것들이 바인딩하려고 하는 셰이더 유니폼 버퍼들과 일치하도록 보장할 책임이 있습니다.

View frustum culling

드라이버와 GPU 가 처리하는 가장 싼 드로는 제출되지 않는 드로입니다. 드라이버와 GPU 의 중복 처리를 피하기 위해, 일반적인 최적화된 렌더링 엔진은 뷰 프러스텀 경계내에 존재하거나 겹치는 것들만을 그래픽스 API 에 제출합니다. 뷰 프러스텀 컬링은 보통 CPU 상에서 싸게 수행되며, 복잡한 3D 씬들을 렌더링할 때는 항상 고려되어야 합니다.

Command buffer binding

Vulkan 은 커맨드 버퍼들이 다중 스레드에서 빌드되는 것을 허용하도록 설계되었으며, 이는 이 비싼 작업들이 다중 CPU 코어들에서 수행될 수 있도록 해 줍니다. 또한, 세컨더리( secondary ) 커맨드 버퍼들이 생성될 수 있으며, 그것은 작업을 더 작은 청크( chunk )로 쪼개는 것을 쉽게 해 줍니다. 세컨더리 커맨드 버퍼는 생성 후에 프라이머리( primary ) 커맨드 버퍼에 커밋( commit )되어야 합니다. 하지만, 일부 구현에서는, GPU 가 렌더 패스 내의 모든 커맨드 버퍼가 단일한 연속된 메모리 블락에 속해 있는 것을 요구합니다 -- 이런 GPU 들을 위한 Vulkan 드라이버들은 커맨드 버퍼가 실행되기 전에 세컨더리 커맨드 버퍼를 프라이머리 커맨드 버퍼로 memcpy() 할 필요가 있습니다. 이러한 부하때문에, 세컨더리 커맨드 버퍼들보다는 프라이머리 커맨드 버퍼들을 선호할 것을 권장합니다. 렌더링을 다중 CPU 코어들 사이에서 다중 스레드로 처리하는 것을 선호한다면, 세컨더리 커맨드 버퍼들을 고려하기 보다는 프라이머리 커맨드 버퍼들을 병렬적으로 빌드하는 것을 권장합니다.

세컨더리 커맨드 버퍼를 사용하기로 결정했다면, 분할 계획( partitioning scheme )을 주의깊게 고려하십시오. 씬이 청크들로 빌드될 때, 여러분의 엔진이 드로 호출 제출 순서를 최적화하고 스테이트( state ) 변경을 최소화하도록 만드는 것이 더 어렵습니다. 세컨더리 커맨드 버퍼 빌드 경로가 구현되었다면, 런타임( run-time )에 그 경로가 요구되는지 혹은 프라이머리 커맨드 버퍼 빌드가 더 빠른지 결정해야 합니다.

Instanced draws

모든 Vulkan CmdDraw* 함수들은 instanceCount 파라미터를 받습니다. 인스턴스 당 데이터는 VkVertexInputBindingDescription::inputRate 를 VK_VERTEX_INPUT_RATE_INSTANCE 로 설정된 버퍼를 바인딩함으로써 제공됩니다.

Clearing framebuffer attachments

Vulkan 에는 프레임버퍼 어태치먼트를 클리어하기 위한 세 가지 메커니즘이 존재합니다 :

• 렌더 패스 로드 연산( VK_ATTACHMENT_LOAD_OP_CLEAR ).
• vkCmdClearAttachments() 함수.
• vkCmdClearColorImage() 함수 및 vkCmdClearDepthStencilImage() 함수.

연산들이 효율적으로 수행되도록 하기 위해서는, 주어진 시나리오를 위해 사용되는 메커니즘을 올바르게 선택하는 것이 중요합니다:

Efficient render pass upscaling

고화질( high-fidelity ) 3D 게임들에서 일반적인 병목은 프래그먼트( fragement ) 셰이딩 실행 시간입니다. 프레임당 프래그먼트 셰이딩 비용을 줄이기 위해, 게임 씬이 줄어든 해상도로 렌더링되고 나서 디바이스의 원래 해상도로 사용자 인터페이스를 렌더링하기 전에 크게 스케일링될 수 있습니다.

• 렌더 패스 A( 줄어든 해상도 )
• 게임 씬 렌더링.
• 렌더 패스 B( 원래 해상도 )
• 게임 씬 이미지를 업스케일링.
• UI 를 렌더링.

업스케일링은 두 가지 방식으로 수행될 수 있습니다:

1. vkCmdBlitImage() 호출.
1. 소스 이미지의 영역들을 대상 이미지로 복사하는데, 잠재적으로 포맷 변환, 임의의 스케일링 및 필터링을 수행합니다.
2. 구현에 따라, 이 연산은 전용 블리팅( blitting ) 하드웨어에 의해 GPU 나 GPU 에서 수행될 수도 있습니다.
2. 전체 화면 사각형 렌더링.
1. 렌더 패스 B 를 이미지를 샘플링하는 전체 화면 드로 호출로 시작합니다.

vkCmdBlitImage() 가 최적의 선택인 것으로 보이겠지만, 모바일 GPU 들에서는 전체 화면 사각형을 렌더링하는 것보다 덜 효율적인 경향이 있습니다. 그 이유는 그것이 하나의 VkImage 로부터 다른 VkImage 로의 명시적인 복사를 요구하기 때문입니다. 블리트 연산을 위해서 GPU 를 사용하는 구현들 상에서는, 이것이 렌더 패스 A 와 B 사이에서 추가적으로 구현되어야 할 것입니다 -- 낭비될 수도 있는 메모리 대역폭과 GPU 사이클을 소비하게 됩니다. 반면에, 전체 화면 사각형 접근법은 단지 한 VkImage 에 대한 레이아웃 트랜지션( transition )만을 요구합니다. 트랜지션의 유형에 따라 이것은 "무료" 로 수행될 수 있도록 구현될 수 있습니다.

Subpasses

모바일 디바이스들은 제한된 메모리 대역폭을 가집니다. 게다가 메모리 대역폭 데이터 전송( transfer )들은 이를 위해 전력을 소비하게 되므로, 가능한 한 적게 사용하는 것이 최상입니다.

3D 그래픽스 렌더링에서, 프레임버퍼는 하나 이상의 어태치먼트들을 필요로 할 것이고 일부 어태치먼트 데이터들은 보존( preserve )될 필요가 있습니다 -- 다른 모든 어태치먼트 데이터는 임시적( temporary )입니다. 예를 들어 컬러 버퍼는 렌더링된 이미지를 위해 요구될 것이고, 뎁스 버퍼는 프리미티브들이 의도된 순서로 렌더링되는 것을 보장하기 위해서 요구될 것입니다. 이 시나리오에서, 뎁스 데이터는 보존될 필요가 없습니다 .그러므로 GPU 메모리에서 시스템 메모리로 그것을 쓰는 것은 대역폭을 낭비하게 됩니다. 또한 N - 1 프레임에 있는 컬러 및 뎁스 버퍼의 내용은 N 프레임에서 요구되지 않습니다. 이 데이터를 업로드하는 것은 메모리 대역폭을 중복으로 사용하기 때문에, 드라이버에게 그런 연산들이 요구되지 않음을 전달하고 싶을 것입니다.

Attachment load op

각 어태치먼트들의 VkAttachmentLoadOp 속성은 어태치먼트들이 서브패스 시작할 때 초기화되어야 하는 방법을 지정합니다.

• VK_ATTACHMENT_LOAD_OP_DONT_CARE
• 이는 가낭 효율적인 선택입니다. 어태치먼트가 초기화될 필요가 없을 때 사용되어야 합니다. 예를 들어 모든 픽셀이 스카이 박스나 어떤 드로에 의해서 칠해지는 경우입니다.
• VK_ATTACHMENT_LOAD_OP_CLEAR
• 이 연산은 타일러( tiler ) 매우 효율적입니다. Clearing framebuffer attachements 섹션에서 기술했듯이, 이것은 렌더 패스를 시작할 때 어태치먼트를 클리어하는 가장 효율적인 방법입니다.
• VK_ATTACHMENT_LOAD_OP_LOAD
• 이것은 가장 비용이 드는 연산입니다. 타일 기반 렌더러에서, 타일( on-tile ) 메모리는 어태치먼트의 보존된 데이터를 시스템 메모리로부터 읽어들임으로써 초기화됩니다.

Attachment store op

각 어태치먼트들의 VkAttachmentStoreOp 속성은 어태치먼트가 서브패스의 끝에서 저장되는 방법을 지정합니다.

• VK_ATTACHMENT_STORE_OP_DONT_CARE
• 이는 가장 효율적인 선택입니다. 어태치먼트가 보존될 필요가 없을 때 사용되어야 합니다. 예를 들어 뎁스와 스텐실 데이터가 이 패스를 렌더링하기 위해서만 사용되는 경우입니다.
• VK_ATTACHMENT_STORE_OP_STORE
• 이는 가장 비용이 드는 연산입니다. 타일 기반 렌더러에서, 타일 메모리는 어태치먼트 이미지를 시스템 메모리로 저장함으로써 보존됩니다.

어태치먼트 이미지가 결코 로드되거나 저장되지 않는다면, VkImage 는 VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT 를 사용해 생성되어야 하며, VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT 속성을 사용해 메모리에 바운딩되어야 합니다. 이는 드라이버가 그 이미지를 임시적( transient )으로 처리할 수 있도록 해 줍니다. 그런 메모리는 나중에 할당될 수 있습니다.

Advanced subpass usage

디퍼드 라이팅( deferred lighting ) 시스템을 위한 같은 멀티 패스 렌더링같은 발전된 서브패스 주제들은 Introduction to Vulkan Render Passes 기사에서 다루고 있습니다.

Synchronization

Vulkan 에서 동기화는 복잡하며, 이를 지원하는 게임에들에서 일반적인 버그들의 온상입니다. 다음 챕터들은 동기화 권장 사항들에 대해서 설명합니다.

Terminology

동기화 개체( primitive )들에 대해서 이해하려고 하기 전에, 이 챕터들을 통해서 사용되는 Vulkan 의 용어들에 대해서 이해하는 것이 중요합니다:

• 동기화 스코우프( Synchronization scope ): 연산들의 집합입니다. 대부분의 동기화 커맨드들에서, 소스( source ) 파이프라인 스테이지 마스크와 대상( destination ) 파이프라인 스테이지 마스크들에 의해 동기화 스코우프들이 정의됩니다.
• 실행 종속성( Execution dependency ): 대부분의 동기화 커맨드들은 실행 종속성을 정의합니다. 첫 번째 동기화 스코우프에서 정의된 모든 연산들은 두 번째 동기화 스코우프 내에서 정의된 모든 연산들보다 먼저 실행되어야 합니다.
• ( 역주 : 접근 ) 가능성 연산( Availability operation ): 이는 다음 메모리 접근이 발생하기 전에 완료되어야 하는 메모리 연산들을 지정합니다. 예를 들어, 이미지 메모리 배리어( barrier )는 VkImage 의 컬러 어태치먼트 쓰기가 다음 접근들 전에 완료되어야 함을 지정합니다.
• ( 역주 : 읽기 ) 가시성 연산( Visibility operation ): 이는 주어진 가능성 연산이 발생하기 전에 한 번만 발생해야 하는 메모리 연산을 지정합니다. 예를 들어, 이미지 메모리 배리어는 지정된 가능성 연산이 완료되기 전에 셰이더가 어태치먼트를 한 번 읽어들이게 됨을 지정할 수 있습니다.
• 리소스 트랜지션( Resource transition ): 어떤 VkImage 리소스들은 가능성 연산과 가시성 연산 사이에서 한 레이아웃에서 다른 레이아웃으로 전이( transition )될 필요가 있습니다. 이미지 메모리 배리어의 경우에, 리소스 트랜지션은 oldLayout 과 newLayout 으로 정의됩니다.
• 메모리 종속성( Memory dependency ): 이는 가시성 연산들의 집합 이전에 완료되어야만 하는 가능성 연산들의 집합을 정의합니다. 메모리 종속성은 리소스 트랜지션을 정의하기도 합니다.

Semaphores

세마포어는 다중 큐 사이에서 리소스 접근을 제어하는 데 사용될 수 있습니다. 가장 일반적인 세마포어의 용례는 그래픽스 큐와 프리젠테이션 큐를 동기화하는 것입니다.

예제: 그래픽스 큐 <--> 프리젠테이션 큐 동기화

코드 블락 1 : Per-Frame

// Acquire an image. Pass in a semaphore to be signalled vkAcquireNextImageKHR(device, swapchain, UINT64_MAX, acquireSemaphore, VK_NULL_HANDLE, &imageIndex); VkPipelineStageFlags waitDstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT; // Submit command buffers submitInfo.waitSemaphoreCount = 1; submitInfo.pWaitSemaphores = &acquireSemaphore; submitInfo.pWaitDstStageMask = &waitDstStageMask; submitInfo.commandBufferCount = 1; submitInfo.pCommandBuffers = &commandBuffer; submitInfo.signalSemaphoreCount = 1; submitInfo.pSignalSemaphores = &graphicsSemaphore; vkQueueSubmit(graphicsQueue, 1, &submitInfo, fence); // Present images to the display presentInfo.waitSemaphoreCount = 1; presentInfo.pWaitSemaphores = &graphicsSemaphore; presentInfo.swapchainCount = 1; presentInfo.pSwapchains = &swapchain; presentInfo.pImageIndices = &imageIndex; vkQueuePresentKHR(presentQueue, &presentInfo);

더 많은 정보를 원한다면 이 페이지를 참고하세요.

Fences

펜스는 큐에서 호스트와 통신하기 위해서 사용될 수 있습니다. 가장 일반적인 용례는 그래픽스 렌더링이 완료되었을 때를 시그널( signal )링하는 것입니다. 그러므로 그 리소스들이 다음 프레임을 위해 재사용될 수 있습니다. 최적의 성능을 위해서는 프리젠트할 이미지들과 리소스들의 개수들 사이를 1:1 로 매핑되도록 하는 것을 추천합니다.

프레임 루프에서 vkWaitForFences() 호출을 피할 것을 추천합니다. 왜냐하면 이것은 실행을 중지( stall )시키고 성능을 감소시키는 결과를 낳기 때문입니다( 우리가 프로우파일링한 게임에서 1-3 fps 정도가 떨어지는 것을 발견했습니다 ). 대신에 vkGetFenceStatus() 를 호출해서 프리젠트할 수 있는 이미지가 이용가능한지를 확인하는 것을 권장합니다.

Example: graphics queue --> host synchronization

코드 블록 2 : Initialization

/* Create a fence for each swapchain index. Default all to signalled so that they are considered "available" in our later test */ fenceInfo.flags = VK_FENCE_CREATE_SIGNALED_BIT; VkFence fences[SWAPCHAIN_IMAGE_COUNT]; for(int i=0; i < SWAPCHAIN_IMAGE_COUNT; i++) { vkCreateFence(device, fenceInfo, NULL, fences); }

코드 블록 3 : Per-frame rendering loop content

Barriers

Vulkan 배리어는 API 사용자가 같은 큐 혹은 같은 서브패스 내의 커맨드들 사이에 종속성을 삽입할 수 있도록 해 줍니다. 실행 종속성은 파이프라인 스테이지 동기화 스코우프에 의해 정의됩니다. 실행 종속성과 함게 vkCmdPipelineBarrier() 호출은 세 가지 유형의 메모리 접근 배리어 -- 전역( global ), 버퍼( buffer ), 이미지( image ) -- 들을 받아들일 수 있습니다. 메모리 배리어들은 API 사용자에게 첫 번째 동기화 스코우프가 완료되는 동안( 혹은 전에 ) 두 번째 동기화 스코우프 내의 읽기 연산전에 쓰기 연산을 보장해 줍니다. 이름이 제안하고 있듯이, 전역 메모리 배리어들은 특정 리소스를 지정하는 것이 아니라 모든 메모리 접근들을 동기화하는 데 사용됩니다. 더 자세한 동기화를 위해서, 버퍼 메모리 배리어와 이미지 메모리 배리어를 사용할 수 있습니다:

위의 표의 네 열은 Vulkan 파이프라인들입니다. TOP_OF_PIPE_BIT 와 BOTTOM_OF_PIPE_BIT 는 모든 파이프라인에 대해 공통입니다. 상대적으로, 그것들은 실행을 시작하고 실행을 종료하는 첫 번째 커맨드를 위한 일반 파이프라인 스테이지들을 표시합니다.

파이프라인 버블( bubble )을 막기 위해서는, API 사용자가 배리어들의 실행 종속성을 매우 주의깊게 고려하는 것이 중요합니다. 배리어 호출을 타일 기반 GPU 아키텍쳐의 서브패스 내에서 하고 있을 때는 특히 중요합니다. 예를 들어 첫 번째 동기화 스코우프에서 BOTTOM_OF_PIPE_BIT 이고 두 번째 동기화 스코우프에서 TOP_OF_PIPE_BIT 인 서브패스 내에서 배리어가 설정되었다면, 배리어 앞에 있는 모든 GPU 커맨드들이 플러싱( flush )되고 배리어 뒤에 있는 커맨드들이 실행을 시작하기 전에 플러싱이 종료되는 것을 위해 대기해야만 할 것입니다.

이러한 버블을 피하려면, 배리어의 첫 번째 동기화 스코우프가 파이프라인의 가능한 한 앞쪽으로 설정되고 두 번째 동기화 스코우프가 가능한 한 가장 마지막의 파이프라인 스테이지로 지정되어야 합니다. scrStageMask 를 TOP_OF_PIPE_BIT 로 설정하는 것은 결코 배리어를 블락킹하지 않으며, 이는 첫 번째 동기화 스코우프가 비어 있는 것처럼 동작합니다. 이와 유사하게 dstStageMask 를 BOTTOM_OF_PIPE_BIT 로 설정하는 것은 두 번째 동기화 스코우프가 비어 있는 것을 의미하게 됩니다. 이러한 동작이 기대되는 경우들이 존재합니다 -- 다른 동기화( 예를 들어 세마포어 )가 이미 요청된 종속성들을 강제하고 있는 경우 -- 하지만 이런 옵션들은 주의깊게 사용되어야 합니다.

자세한 버퍼 동기화가 요구되지 않는 한은 전역 메모리 배리어들이 버퍼 메모리 배리어보다 선호됩니다. -- 예를 들어 버퍼의 특정 영역을 쓰는 동기화입니다. 같은 동기화 스코우프에 의존하는 이미지 메모리 배리어와 버퍼 메모리 배리어는 단일 vkCmdPipelineBarrier() 호출 내부에 배칭( batch )해야 합니다.

Events

이벤트들은 자세한 동기화 메커니즘을 제공합니다:

• 호스트에서 그래픽스 큐로의 동기화.
• 렌더 패스 내부에서의 커맨드 종속성들.

vkCmdWaitEvents() 는 vkCmdPipelineBarrier() 와 유사한 인자들을 취합니다. 추가적인 인자들은 eventCount 와 pEvents 입니다. pEvents 와 srcStageMask 에 의해 정의되는 동기화 스코우프는 vkCmdWaitEvents() 와 dstStageMask 뒤쪽의 커맨드들이 실행되기 전에 종료되어야 합니다.

호스트에서 그래픽스 큐로의 이벤트 동기화는 커맨드 버퍼에 쓰여진 리소스들에 대한 종속성이 있는 커맨드들 뒤쪽에서 리소스 쓰기가 발생할 필요가 있을 때 유용합니다. 예를 들어, 사용자 입력과 GPU 실행 사이의 지연을 줄이기 위해서, VR 합성기( compositor )는 타임 워프 합성이 수행되기 전에 유니폼 버퍼에 씬이 렌더링되므로 머리 방향 델타( delta )를 표현하는 행렬을 쓸 수 있습니다. vkCmdWaitEvents() 는 이 이벤트가 시그널링될 때까지 실행을 블로킹합니다. 하지만 너무 많은 시간이 걸리는 GPU 제출( submission )은 시스템에 의해 무시( kill )될 수 있다는 점을 기억하십시오. 그래서 이러한 접근법을 사용하려면 극도의 주의가 필요합니다.

Wait idle

아이들 대기는 동기화에서 매우 무거운 형식입니다. vkQueueWaitIdle() 은 모든 큐 연산들이 종료될 때까지 대기하며 기능적으로는 펜스를 기다리는 것과 동일합니다. vkDeviceWaitIdle() 은 모든 디바이스 연산이 종료될 때까지 대기합니다. 아이들 대기 함수들은 중복이 없음이 보장하며, and should only be used for rendering engine tear down.

SwapChains

스왑체인을 생성할 때, VK_PRESENT_MODE_FIFO_KRH 프리젠테이션 모드를 사용하고 minImageCount 를 3 으로 설정하는 것을 권장합니다.

VK_PRESENT_MODE_MAILBOX_KHR 프리젠테이션 모드는 잠재적으로 프레임율을 안정화시켜 줍니다; 하지만 이는 렌더링된 전체 프레임을 날림( throwing )으로써 수행됩니다. 이는 GPU 가 필요 이상으로 무거워지도록 만듭니다( 그리고 결국 더 많은 전력을 소비합니다 ). FIFO 를 사용하여 프로우파일링하고 최적화할 것을 강력히 권장합니다. 그리고 MAILBOX 는 최소 지연이 절대적으로 요구될 때만 사용하십시오.

스왑체인 이미지의 개수를 결정하는 데 대한 주요 고려사항은 메모리 사용과 부드러움 사이의 균형입니다. 안드로이드는 2 개의 이미지만을 가진 스왑체인을 생성하는 것을 지원합니다. 이는 요구되는 메모리를 줄여주지만, 프레임이 v-sync 를 위한 시간 내에 렌더링되지 못한다면 렌더링 파이프라인에서 버블을 만듭니다. 3 개 보다 많은 스왑체인 이미지를 요청할 수 있기는 하지만, 이는 이러한 이점과 추가적인 메모리 소비량 사이에서 주의깊게 고민해 봐야 합니다.

그래픽스 큐와 프리젠테이션 큐를 동기화하기 위해서 세마포어를 사용해야 합니다. 펜스는 그래픽스 큐와 호스트를 동기화하기 위해 사용되어야 합니다. 더 많은 정보를 원한다면 다음 예제들을 참고하십시오:

• 예제 : 위의 코드블락 1, 2.

Minimizing overdraw

프래그먼트들은 프리미티브가 그래픽스 큐에 제출된 순서대로 래스터화( rasterize )됩니다. 여러 개의 프리미티브들이 겹쳐 있으면, 결과 프래그먼트들이 최종 이미지의 다른 것들에 의해 가려지는 상황이라고 할지라도 모든 프래그먼트들이 렌더링됩니다. 이후의 프래그먼트들에 의해 겹쳐지게 되는 값을 가진 프래그먼트들을 렌더링하는 것은 오우버드로( overdraw )라 알려져 있습니다.

일부 아키텍쳐들만 나중에 무시될 프래그먼트에 대한 셰이딩 부하를 줄이는 최적화를 포함하고 있습니다. 그럼에도 불구하고, 최상의 휴대용 최적화를 획득하기 위해서는, 초기 뎁스/스텐실 테스트를 사용하고 불투명 드로 호출들을 깊이 순서대로( 일반적으로 앞에서 뒤로, 뎁스 테스트 모드에 따라 다름 ) 제출하는 것을 권장합니다. 이는 GPU 가 셰이딩을 위한 가시적인 우선순위를 가지고 있는 프리미티브들이 어떤 것인지 판단할 수 있도록 해 줍니다. 투명 프리미티브들은 불투명 프리미티브들 후에 블렌딩 동작을 유지할 수 있는 순서로 렌더링되어야 합니다.

Avoid redundant API calls

렌더링없이 반복적으로 스테이트를 설정하는 것과 같은 Vulkan 중복 호출들은 병목을 유발하지 않습니다만, 여전히 비용이 듭니다.

Robust Buffer Access

Vulkan 드라이버들은 API 가 그것을 호출하는 애플리케이션 내에서 올바르게 사용되고 있다고 가정합니다. 이러한 가정은 드라이버가 런타임 유효성 검사를 피할 수 있도록 해 줍니다. 애플리케이션들은 robustBufferAccess 기능을 활성화함으로써 더 강력한 신뢰성 보장을 요구할 수 있습니다. 신뢰성있는 버퍼 접근의 주요 목적은 버퍼 경계를 넘어서는 것과 관련한 검사들을 제공하는 것입니다. Vulkan 명세는 robustBufferAcess 가 물리 디바이스 상에서 이용가능한 기능임을 보장하지만, 그것을 활성화하는 것은 일부 아키텍쳐에서 심각한 성능 페널티를 발생시킬 수 있습니다.

Validation Layers

API 오용을 식별하기 위해서 개발 단계 동안 주기적으로 크로노스 그룹의 Vulkan 유효성 레이어들을 사용해야 합니다. 최상의 결과를 위해서, 최신 버전의 유효성 레이어들을 사용하는 것을 권장합니다. 유효성 레이어들의 소스 코드는 깃허브에서 호스팅되고 있으며 그것을 빌드하는 것은 직관적입니다. 각 레이어의 릴리스들에는 sdk-* 라는 태그가 붙어 있습니다.

이용가능한 레이어들의 하위 집합에 의존해서는 안 됩니다. 모든 잠재적인 문제들을 발견하기 위해서는 크로노스에서 제공하는 모든 레이어들을 주기적으로 사용할 것을 권장합니다.

렌더링 엔진은 서로 다른 디바이스 상에서 서로 다른 Vulkan 기능들( 예를 들어 텍스쳐 포맷 )을 사용할 것입니다. 그래서 여러 Galaxy 디바이스를 사용해 유효성 레이어들을 실행하는 것을 권장합니다. 게임을 릴리스하기 전에 모든 유효성 레이어 메시지들을 해결해야 합니다.

에러코드는 메시지에 특정되지 않습니다.그것들은 문제의 유형을 분류하며 하나 이상의 메시지들에 이해 재사용될 것입니다. 레이어 출력을 파싱하는 것을 권장하지는 않습니다. 왜냐하면 에러 코드와 메시지 텍스트는 유효성 레이어 릴리스마다 다양하기 때문입니다.

레이어에 의해 보고된 메시지의 의미가 명확하지 않다면, 원인을 더 잘 이해하기 위해서 유효성 소스 코드를 검색해 볼 것을 권장합니다.

잘못된 긍정( positive )이나 잘못된 API 용례가 발견되지 않는 시나리오들을 인지했다면, 깃허브의 레이어에 대한 문제에다가 보고해 주십시오.

크로노스 유효성 레이어들에 대해 더 알고자 한다면, LunarG 의 Vulkan Validation Layers Deep Dive 슬라이드를 읽어보실 것을 권장합니다.

원문 : https://gpuopen.com/performance-root-signature-descriptor-sets/

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

주의 : 허락받고 번역한 것이 아니라 언제든 내려갈 수 있습니다.

Direct3D 12 와 Vulkan 이전에는 리소스들이 "슬롯( slot )" 을 통해서 셰이더에 바인딩되었습니다. 여러분들 중 일부는 하드웨어가 첫 번째 유닛에 텍스쳐를 바인딩하고 두 번째 유닛에 라이트 맵을 바인딩할 것을 요구했던 소수의 고정함수( fixed-function ) 유닛( unit )들만을 가지고 있었다는 것을 기억할 것입니다. OpenGL 와 Direct3D 11 까지의 바인딩 시스템은 이러한 잔재( heritage )를 보여줍니다. 두 API 에서는 심지어 하드웨어가 이 모델에서 발전했음에도 불구하고 리소스를 바인딩할 수 있는 슬롯 집합이 존재했습니다.

새로운 바인딩 모델에 대해서 살펴 보기 전에, 현대의 GCN 기반 GPU 가 리소스를 식별하는 방법에 대해서 살펴 보겠습니다. 우리가 텍스쳐( texture )에 접근하려고 한다고 해 봅시다 -- 이것이 어떻게 텍스쳐 샘플링 명령( instruction )으로 전달되는 것일까요? GCN ISA 문서를 살펴 보면, 다음과 같은 구절을 찾을 수 있을 것입니다:

모든 벡터 메모리 연산( operation )들은 이미지 리소스 상수( constant ) (T#) 을 사용하는데, 그것은 SGPR 들 안의 128 비트 혹은 256 비트 값입니다. 이 상수는 명령이 실행될 때 텍스쳐 캐시로 전송됩니다. 이 상수는 메모리 상의 서피스에 대한 주소, 데이터 포맷, 특성( characteristics )을 정의합니다.

그러므로 이제 슬롯으로 사용되는 것은 텍스쳐 샘플링 명령으로 넘겨지는 레지스터 집합( couple of registers )들입니다. 다음 구절은 더 흥미롭습니다:

일반적으로 이 상수들은 메모리로부터 페치( fetch, 전송 )됩니다.

이는 텍스쳐를 기술하기 위해서 필요로 하는 모든 것들이 메모리의 아무 곳에나 배치될 수 있는 작은 디스크립터( descriptor, 기술자 )( 128 비트 혹은 256 비트 )라는 것을 의미합니다. 그것이 레지스터에 로드되어 있는 한 올바르게 진행되고 있는 것입니다. 이 문서의 나머지 부분을 읽게 되면, 모든 다른 리소스 유형들에 대해서도 같은 패턴이 사용되고 있다는 것을 알게 될 것입니다. 사실, 리소스 접근을 하게 될 때 "슬롯" 이라는 것은 존재하지 않습니다 -- 대신에 모든 것은 텍스쳐 디스크립터( 혹은 T# ), 샘플러( sampler ) 디스크립터( S# ), 혹은 상수 ( V# ) 을 통해서 진행됩니다. Direct3D 12 와 Vulkan 을 사용하면, 이러한 디스크립터들이 최종적으로 그 자체로서 노출됩니다 -- 일부 GPU 메모리.

GCN 하드웨어에는 특별한 레지스터 집합 -- "사용자 레지스터" 라 불림 -- 들이 존재하는데, 이것들은 디스크립터( 그리고 상수들 -- 아래에서 더 살펴 볼 것임 )들을 저장하는 데 사용됩니다. 이런 레지스터들의 개수는 디스크립터 저장소마다 다른데요, 셰이더 스테이지( stage ), PSO , 드라이버에 의존합니다. 하지만 일반적으로 대충 12 개( dozen ) 정도 됩니다. 각 레지스터는 디스크립터, 상수, 포인터를 사용해 프리로드( pre-load )될 수 있습니다. 레지스터 공간이 넘치면, 드라이버가 메모리의 spill space 를 사용해 더 큰 테이블( table )을 에뮬레이트( emulate )합니다; 이 때 CPU 비용( spill table 관리 -- spill 영역이 변경될 때마다 발생 )과 GPU 비용( 추가적인 포인터 간접 참조( indirection ) )이 모두 발생합니다. 결과적으로, 일제히 변경하는 디스크립터들이나 상수들의 블록들을 가지고 있다면, 그것들을 개별적으로 저장하고 포인터를 사용하여 그것들이 넘치지 않도록 하는 것이 더 낫습니다.

Vulkan resource binding

Vulkan 에서 바인딩 모델은 다음과 같이 설명될 수 있습니다. 디스크립터들은 디스크립터 셋에 배치되고, 하나 이상의 디스크립터 셋을 바인딩할 수 있습니다. 디스크립터 셋 내부에서는 모든 디스크립터 유형들을 자유롭게 섞을 수 있습니다. 또한 레지스터에 프리로드할 수 있는 상수들인 "push constants" 들도 존재합니다.

왼쪽의 블록은 API 에서 암시적( implicit )입니다 -- 여러분은 현재 바인딩되어 있는 것을 볼 수 없습니다 -- 그리고 오른쪽의 블록들은 개별 디스크립터 셋들입니다. 위에서 배웠듯이, 디스크립터 셋들은 플레인 메모리( plain memory, 역주 : 메모리의 구조가 명확함 )입니다. 그래서 모든 패킹( packing ), 캐시 적중( cache hit ) 등과 같은 모든 조언들이 여기에도 적용됩니다. 같이 사용하려고 하는 디스크립터를 가깝게 배치하십시오. 가능하면 인접한( consecutive ) 엔트리( entry )들을 로드하십시오. 메모리 주소들에 접근할 때 큰 점프( jump )를 피하십시오. 텍스쳐와 함께 사용하고자 하는 샘플러들에 대한 정보를 더 알고 있다면, 그것들을 샘플러와 텍스쳐를 가깝게 배치하는 "combined image sampler" 로 결합함으로써 디스크립터 셋을 최적화할 수 있습니다.

동적 버퍼( dynamic buffer ) 디스크립터들에 대해서 궁금할 것입니다: 그것들은 버퍼와 옵셋( offset )에 대한 접근을 제공합니다. 그것들은 기본적으로 플레인 상수를 가진 혼합 버퍼 디스크립터입니다. 이 상수들은 레지스터들을 사용하게 되므로, 많은 동적 버퍼들에서 문제가 될 수 있습니다. 이를 우회하기 위한 두 가지 방법이 존재합니다. 인덱싱( indexing )중인 데이터가 동일한 너비( uniform stride )를 가지고 있다면, 그냥 그 버퍼들을 바인딩하고 단일 상수( 혹은 다른 버퍼 내에 저장된 다중 상수들 )를 사용해 인덱싱하면 됩니다. 만약 너비가 고정되지 않았지만 옵셋을 알고 있다면, 디스크립터 배열을 생성하고 대상 위치로 점프하도록 인덱싱할 수 있습니다. 다시 말해, 여러분이 처음 사용하는 인덱스가 단일 상수인지 다른 버퍼로부터의 인덱스인지 확인해야 합니다.

Direct3D resource binding

Direct3D 는 루트 시그너쳐( root signature )를 통해서 암시적 바인딩을 노출하는데, 이는 실시간에 관리됩니다. 이는 위에서 설명했던 사용자 레지스터들 상에서 매우 직관적으로 매핑합니다. 하지만 API 에는 몇 가지 제약들이 존재합니다: 테이블 내의 다른 디스크립터들을 사용해 샘플러 디스크립터들을 저장할 수 없습니다. 또한 루트 시그너쳐에는 디스크립터 테이블, 루트 시그너쳐, 버퍼 포인터에 대한 포인터만이 포함될 수 있습니다. 컴파일타임에 샘플러 디스크립터를 지정할 수 있는 한 가지 대안이 있기는 하지만, 텍스처 디스크립터나 샘플러 디스크립터를 루트 시그너쳐에 배치할 수는 없습니다.

혼합된 텍스쳐 디스크립터와 샘플러 디스크립터는 존재하지 않습니다; 대신에 분리된 디스크립터 힙( heap )들에 저장되어야만 합니다.

그것을 제외하고는 바인딩 모델은 Vulkan 과 동일합니다. 그리고 디스크립터를 통해 리소스들에 접근할 것을 요구합니다. 둘의 주요한 차이는 루트 시그너쳐가 특정한 종류의 디스크립터들이 인라인( in-line )으로 저장되는 것을 허용한다는 것입니다. 반면에 Vulkan 은 모든 경우에 디스크립터 셋을 통해서 진행하는 것을 기대합니다.

Performance guidelines

최적화의 시작점은 루트 시그너쳐를 가능한 한 작게 유지하는 것입니다. 루트 시그너쳐가 커진다는 것은 spill 이 될 확률이 올라가고 파라미터들을 유효화( validating )할 때 드라이버에 전달될 더 많은 엔트리들이 필요함을 의미합니다. 이는 디스크립터 테이블을 적게 바인딩하고, 큰 상수들을 설정하는 것을 피하고, 피할 수 있다면 Direct3D 에서 버퍼 뷰를 사용하지 않아야 함을 의미합니다. 단일 상수 버퍼 뷰가 용납될 수 있기는 하지만, 항상 바인딩되어 있는 큰 상수 버퍼 내의 옵셋을 제공하는 상수를 사용하는 것이 좋습니다. 아래의 루트 시그너쳐를 살펴 봅시다:

그것은 포인터로 시작해서, 몇 개의 루트 상수들, 몇 개의 포인터들, 그리고 두 개의 디스크립터들로 끝납니다. 그 두 개의 디스크립터들이 넘쳐흐를 가능성이 존재하므로, 드라이버가 관리하는 오우버플로우( overflow ) 버퍼들을 만나게 될 것입니다. 루트 시그너쳐를 가능한 한 작게 유지해서 이러한 문제를 피하십시오!

어쨌든 항상 가장 자주 변경되는 파라미터들을 목록의 앞에 유지하도록 노력해야 합니다. 만약 spill 이 발생하면 주파수가 급격히 떨어지며, 파라미터들을 유효화시 드라이버 부하도 줄어들 것입니다. 이는 드라이버가 오우버플로우 처리 상수( overflow handling constant )를 유지할 수 있도록 합니다. 그리고 가장 자주 변경되는 엔트리가 성능을 위해 레지스터에 남아 있도록 합니다.

오늘은 이만! 질문이 있다면 자유롭게 댓글을 남기거나 Twitter 에서 ping 해 주세요:  @NThibieroz & @NIV_Anteru.

Tweets

• 07: Keep your root descriptor set small and place most frequently changed entries first.
• 17: Order root signature parameters by change frequency (most frequent to least frequent).
• 27: Keep your descriptor sets constant, reference resources that belong together in the same set.
• 36: Use as few root signature slots as possible. Frequently updated slots should be grouped at the beginning of the signature
• 44: Try to make root signatures as small as possible (create multiple root signatures if needs be).
• 49: If using multiple root signatures, order/batch draw calls by root signature.
• 54: Only constants or constant buffers changing every draw should be in the root signature.

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.

주의 : 초심자 튜토리얼은 아닙니다. 그러므로, 실제 API 호출 용례를 알고자 한다면, 샘플이나 튜토리얼을 찾아서 확인해 보세요.

주의 : 완전히 이해하고 작성한 글이 아니므로 잘못된 내용이 포함되어 있을 수 있습니다.

주의 : 이상하면 참고자료를 확인하세요.

D3D 에 익숙한 사람이 벌칸을 할 때 발견하게 되는 어려운 개념 중에 하나는 디스크립터 셋 레이아웃( Descriptor Set Layout )입니다. 일단 디스크립터라는 것의 개념 자체를 모르는 상황이기 때문에 당연합니다.

사실 어려운 개념은 아니지만 생소하기 때문에 어렵게 느껴집니다. 디스크립터에 대해서 이해하기 위해서는 벌칸 명세에 있는 파이프라인 블록 다이어그램을 보는 것이 도움이 됩니다.

그림 1. Block diagram of the Vulkan pipeline. 출처 : [ 1 ].

그림 1 에 나타나 있듯이 디스크립터는 셰이더에 바인딩할 수 있는 리소스에 대한 정보를 의미하며 그것들의 모임이 디스크립터 셋이 됩니다.

이제 명세로부터 정확한 정의를 찾아 보도록 하죠.

디스크립터는 버퍼, 버퍼 뷰, 이미지 뷰, 조합된 이미지 샘플러와 같은 셰이더 리소스들을 표현하는 불투명( opaque ) 데이터 구조입니다. 디스크립터들은 디스크립터 셋을 구성하는데요, 그것들은 일련의 드로 커맨드들 내에서 사용할 커맨드들을 기록하는 동안 바인딩됩니다. 각 디스크립터 셋에서 칸텐트의 배열( arrangement )은 디스크립터 셋 레이아웃에 의해 결정됩니다. 그것은 어떤 디스크립터들이 저장되어 있는지를 결정합니다. 일련의 디스크립터 셋 레이아웃들은 파이프라인 레이아웃( pipeline layout )에 지정되어 있는 파이프라인에 의해 사용될 수 있습니다. 각 파이프라인 오브젝트들은 maxBoundDescriptorSets 만큼 까지의 디스크립터 셋들을 사용할 수 있습니다.

셰이더들은 디스크립터 셋과 디스크립터 셋 내에서 리소스와 디스크립터를 연결하는 바인딩 번호가 부여된( decorated ) 변수들을 통해 리소스들에 접근하게 됩니다. 디스크립터 셋들을 바운딩하기 위한 셰이더 인터페이스 매핑( shader interface mapping )에 대해서는 Shader Resource Interface 섹션에서 다루고 있습니다.

출처 : Chapter 13. Resource Descriptors, [ 1 ].

우리는 디스크립터 셋 레이아웃을 렌더패스/서브패스 개념과 유사하게 생각해 볼 수 있습니다. 렌더패스와 서브패스는 프레임버퍼의 설계도처럼 동작합니다. 렌더패스와 서브패스가 프레임버퍼의 바인딩 구조를 결정하고 실제 렌더링시에는 프레임버퍼가 바인딩됩니다. 그리고 이 프레임버퍼에는 실제 이미지 뷰들이 바인딩되어 있죠. 

마찬가지로 디스크립터 셋 레이아웃은 디스크립터 셋의 설계도라고 생각하시면 됩니다. 그리고 실제 렌더링시에는 디스크립터의 묶음인 디스크립터 셋이 바인딩되는 것입니다.

그림 2. 디스크립터 셋 레이아웃. 출처 : [ 2 ] 의 7 분 47 초 부분.

디스크립터 종류는 VkDescriptorType 에 기술되어 있습니다.

typedef enum VkDescriptorType { VK_DESCRIPTOR_TYPE_SAMPLER = 0, VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER = 1, VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE = 2, VK_DESCRIPTOR_TYPE_STORAGE_IMAGE = 3, VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER = 4, VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER = 5, VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER = 6, VK_DESCRIPTOR_TYPE_STORAGE_BUFFER = 7, VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC = 8, VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC = 9, VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT = 10, VK_DESCRIPTOR_TYPE_MAX_ENUM = 0x7FFFFFFF } VkDescriptorType;

그런데 이 디스크립터라는 것은 리소스 오브젝트를 의미하고 있기 때문에 실제로는 디스크립터라는 오브젝트가 따로 존재하지는 않습니다. 디스크립터 셋에 의해서 디스크립터라는 것이 규정되는 것이죠. 마치 프레임버퍼라는 오브젝트에 이미지 뷰를 바인딩하는 것과 유사합니다.

디스크립터 셋은 디스크립터 풀( Descriptor Pool )인 VkDescriptorPool 오브젝트에 할당됩니다. 디스크립터 셋이라는 것은 셰이더의 종류가 늘어나면 많이 존재할 수 있기 때문에 풀이 필요합니다. 

풀은 외부 동기화( externally synchronized )되기 때문에 여러 스레드에서 동시에 접근해서는 안 됩니다. 그러므로 가급적이면 스레드마다 하나씩 존재하거나 직접 동기화 처리를 해야겠죠. 하지만 동기화 비용을 없애기 위해서는 스레드 별로 존재하는 것이 좋을 것입니다.

이 시점에 다음과 같은 그림을 그려 볼 수 있습니다.

그림 3. 디스크립터 풀과 디스크립터 셋.

이것을 파이프라인 스테이지와 연동시켜서 보면 다음과 같은 형태를 띠게 됩니다.

그림 4. 파이프라인 스테이지와 디스크립터 셋 레이아웃. 출처 : [ 3 ].

그런데 여기에서 하나 알아 둘 것이 있습니다. 명세에서는 파이프라인 내의 스테이지들이 같은 바인딩 번호를 통해 리소스에 접근할 수 있다고 하고 있습니다.

그림 4 를 보시면 알겠지만, 하나의 파이프라인에 여러 개의 디스크립터 셋들이 바인딩될 수 있습니다. 그러므로 그 디스크립터 셋들을 정의하면서 바인딩 번호를 동일하게 설정하면 같은 데이터에 접근하는 것이 가능합니다. 셰이더에서 레이아웃은 다음과 같은 식으로 지정됩니다.

layout(set = 0, binding = 0) uniform UniformBufferObject { ... }

만약 HLSL 과 DXC 를 사용한다면 register 를 통해서 디스크립터 셋의 레이아웃을 지정할 수 있습니다.

:register(xX, spaceY)

'X' 는 바인딩 번호이고, 'Y' 는 디스크립터 셋을 의미합니다. 

그런데 register 에 의존하지 않고 [[vk::binding(X[, Y])]] 와 [[vk::counter_binding(X)]] 애트리뷰트를 사용하는 것도 가능합니다. 자세한 사항은 [ HLSL to SPIR-V Feature Mapping Manual ] 에서 확인하시기 바랍니다.

튜토리얼 개념으로 쓴 글이 아니다 보니 여기에서 구체적인 API 와 코드에 대해서 집중적으로 다루지는 않았습니다. 개념을 이해하는 것이 중요하다는 생각에 정리해 봤으니 자세한 코드는 튜토리얼들에서 살펴 보시기 바랍니다. 잘못된 내용이 있으면 지적해 주시기 바랍니다.

참고자료

[ 1 ] Vulkan Specification 1.1.123. Khronos Group.

[ 2 ] Vulkan Tutorial 5: Triangle Sample Walkthrough, Qualcomm Developer Network.

[ 3 ] Siggraph 2016 - Vulkan and NVidia : the essentials.

원문 : https://www.micromine.com/what-is-implicit-modelling/

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

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

정보 : 본문에서는 수학적 개념을 다루고 있으므로 "implicit function" 을 "음함수", "explicit function "을 "양함수", "parametric function" 을 "매개변수함수"라 번역합니다.

Paul Hooykaas

November 19, 2014

Introduction

모든 사람들이 음함수 모델링( implicit modeling ) 행사에 뛰어 들고 싶어하는 것으로 보입니다. Orefind 블로그 페이지에서는 이 유행을 반영하는데, 2012 년 후반부터 적어도 6 개의 관련 기사들이 있습니다 -- Jun Cowan 과 Ron Reid 가 주목할 만한 기여자들입니다.

불행하게도, 업계에서는 "음함수 모델링" 이라는 개념에 대한 일과된 이해가 없어 보입니다. 제가 불행하다라고 이야기한 이유는 원래의 정의는 "진짜" 라는 한정자를 필요로 하지 않음에도 리뷰어( reviewer )들이 이제 "진짜 암시적 모델링" 이라고 부르를 정도까지 타협이 일어나고 있기 때문입니다.

그래서 여기에서는 음함수 모델링이 실제로는 무엇인지 명확하게 해 보려고 합니다. 이 개념은 광물 자원 분야( mineral resources sector )에서는 상대적으로 새로 등장한 것입니다만, 컴퓨터 그래픽스 업계는 1960 년 후반부터 기반 기법들을 사용해 오고 있습니다. Jules Bloomenthal 의 ( 1995 년 1 월의 ) 논문인 Skeletal Design of Natural Forms 으로부터 발췌한 내용을 고려해 봅시다.

기하 모델링( geometric modeling )은 종종 파라미터( parametric ) 기법과 음함수( implicit ) 기법으로 분류됩니다. 둘 다 컴퓨터 그래픽스로부터 개발되었습니다(  [Coons 1967] 에서 초기 파라미터 기법이 소개되었고, [Mathematical Applications Group 1968] 에서 초기 음함수 기법이 소개되었습니다. 음함수 서피스들은 더욱 손쉽게 볼륨 관계( volumetric relationship )들을 수집( capture )합니다...

수학에서 "음함수" 라는 단어는 더 오랜 역사를 가지고 있으며, 그것은 특별한 유형의 함수를 기술하기 위해서 사용됩니다.

Implicit or Explicit

"음함수 모델링" 은 2003 년 11 월 벤디고( Bendigo )에서 열린 5 회 국제 광산 지질학 컨퍼런스( international mining geology conference )에서 제출된 논문에서 Jun Cowan 에 의해 탐사( exploration ) 업계와 광산 업계에 소개되었습니다. 이 기사의 많은 부분들은 그 논문의 내용을 반복한 것입니다.

아마도 음함수 모델링과 관련된 개념들을 강조하기 위해서, 그 논문은 ( 수작업 디지털화( manual digitizing )에 매우 의존하는 ) 전통적인 모델링 기법들을 '양함수' 라고 기술한 것 같습니다. 필자는 이러한 언급이 무심코 오늘날 우리가 인지하게 된 혼란의 일부 원인이 된 것이라 생각합니다. 매일 대화를 하면서 '음함수' 와 '양함수' 라는 단어들은 반대 의미로 쓰입니다( 후자는 "완전히 명확하게 정의된" 을 의미하고 전자는 "직접적으로 표현되지 않은" 을 의미합니다 ). 두 단어들을 모델링 프로세스( process )와 연관시킴으로써, 모든 메서드들이 이 두 가지 분류 중 하나로 들어 가야 한다고 여겨지게 되었습니다. 양함수 기법을 이해하는 것이 쉬웠기 때문에, 수작업 디지털화를 배제한 적절한 출력을 생성하는 모든 프로시저( procedure )들을 "음함수" 라고 여겨지도록 분류하는 것이 편했습니다. 예를 들어, 3D 블록 모델로부터 하나 이상의 등급 셸( grade cell )을 생성하는 것은 음함수 모델링의 형태라고 주장하는 것이 일반적( popular )입니다. 이것은 '음함수' 이라는 기술자( descriptor )가 일반적인 용법이 아니라 수학적인 의미에서 생겨났다는 것을 알게 되면 그리 이상한 것은 아닙니다.

Curves and Surfaces

이 주제에 대한 많은 참고 자료( reference material )들은 '커브( curve )' 와 '서피스( surface )' 에 대해 언급합니다. 커브와 서피스의 수학적 정의에 대해서 언급하는 것은 중요합니다. 왜냐하면 그것들은 이런 개념들에 대한 표준적인 이해와는 약간 다르기 때문입니다:

• 커브는 라인( line )과 유사하지만 직선일 것을 요구받지 않습니다. 열린( open ) 커브는 시작 점과 끝 점이 다릅니다. 닫힌( closed ) 커브는 시작점과 끝이 만납니다. 그러므로 닫힌 커브에는 끝 점이 없습니다.
• 놀랍게도 서피스의 ( 기하학적( geometric ) ) 정의는 '매니폴드( manifold )' 와 '유클리드( Euclidean )' 과 같은 기술적인 개념들로 빠르게 어수선해질 수 있습니다. 단순한 설명은 "솔리드( solid, 역주 : 안이 채워진 도형? ) 경계의 일부 혹은 전체" 입니다. 그런 서피스들의 중요한 점은 커브처럼 열려있거나 닫혀있다는 것입니다. 평면( plane )은 열린 서피스의 단순한 예입니다. 그리고 구( sphere )는 닫힌 서피스의 단순한 예입니다. 이것을 바라보는 다른 방식은 열린 서피스가 면적을 가지고 있고 닫힌 서피스가 부피를 가지고 있다는 것입니다.

Function Types

자, 수학 문맥에서 "음함수" 는 어떤 의미일까요? 수학에서는 ( 커브의 ) x, y 사이의 관계나 ( 서피스의 ) x, y, z 사이의 관계를 함수라고 부르며, 세 가지 종류의 구별되는 함수 유형이 존재합니다: 양함수, 음함수, 매개변수함수.

노트 : 

1. 위는 변수 x 와 y 를 사용하는 커브( 혹은 라인 )에 기반합니다. z 변수를 사용함으로써 서피스를 포함하는 논의로 확장하는 것이 가능합니다.
2. 함수와 공식( equation ) 사이에는 약간의 차이가 있습니다만, 여기에서는 무시합니다.

양함수들은 x 값으로부터 직접적으로 y 값을 생성합니다. 그래서 원 상에 존재하는 점들의 수열을 생성하는 것이 상대적으로 쉽습니다. 하지만 ( 닫힌 라인이나 서피스가 지원되지 않는 ) 단일 값 제약( single value restriction )에 의해 양함수 형태는 우리 목적에 맞지 않게 됩니다.

음함수들은 "implicit" 라는 단어의 일반적인 용법과 연결됩니다. 원 예제에서 음함수는 x² + y² - r² = 0 이라는 것을 기억하세요. 이에 기반해서 특정 반지름( 2 라고 하죠 )이 주어졌을 때 원을 어떻게 그려야 할 것인지 생각해 보세요. 원 위에 있는 연속된 점들을 체계적으로( systematically ) 생성할 수 있는 직접적인 방법이 존재하지 않습니다. 그리고 이것이 이 표현이 음함수라고 불리는 이유입니다. 원이 거기 존재한다 -- 확실히 잘 정의되어 있습니다 -- 는 것을 알고 있습니다만, 그것을 가시적으로 표현하는 것은 문제입니다.

하지만 음함수 형태는 자신만의 특별한 특성을 가지고 있습니다. ( 반지름이 알려진 값인 ) 특별한 원의 경우에, 우리는 모든 x, y 를 공식에 대입할 수 있습니다. 만약 그 결과가 양수라면 그 점은 원 밖에 존재합니다. 만약 결과가 음수라면 그 점은 원 안에 존재합니다. 만약 결과가 0 이라면 그 점은 원 위에 존재합니다. 다시 말해 모든 점에 대한 '분류( classification )'를 쉽게 할 수 있습니다.

한편으로 파라미터 표현은 원을 그리는 매우 편리한 방법을 제공합니다. t = 0 에서 시작해 x 와 y 를 계산합니다. 이제 적은 양만큼 t 를 증가시키면서 다음 x 와 y 를 계산합니다. 이를 t = 2π 가 될 때까지 계속 진행합니다...

An Implicit Model

변수를 포함하고 있지만 측정 가능한 속성( attribute )을 가진 3D 볼륨( volume )에 대해 생각해 보죠. '속성' 은 광석( ore ) 몸체의 밀도( density ), 온도( temperature ), 등급( grade )일 수 있습니다. 실제 측정값들은 분산된 데이터 포인트들로부터 취해집니다. 그 데이터 포인트들은 볼륨 상의 속성에 대한 연속적인 수학적 표현을 제공하기 위한 음함수들을 유도하기 위해서 사용될 수 있습니다. 이 음함수 모델은 무한한 개수의 isosurface -- 상수값의 점들을 표현하는 서피스 -- 들을 포함합니다. 등급 셸은 isosurface 에 대한 친숙한 예입니다.

하지만 음함수 모델 자체는 가시화될 수 없습니다. 그렇게 하기 위해서는 모델로부터 하나 이상의 isosurface 들을 추출하고 이를 3D 공간에 그려야 합니다. 만약 모델이 파라미터 형식으로 변환될 수 있다면 isosurface 추출은 쉬워질 것입니다. 하지만 사는 게 그렇게 쉽지는 않습니다. 동일한 파라미터 해법을 찾아내는 것은 너무 멀리 있는 희망입니다.

원 예제에서 살펴 봤듯이, 음함수 모델은 체계적으로 isosurface 상의 점들을 생성하기 위한 직접적인 방법을 가지고 있지 않습니다. 그것은 점이 그 서피스 상에 존재하는 지, 위쪽이나 아래쪽에 존재하는지를 결정하는 테스트를 제공합니다. 하지만 서피스 점들 자체를 생성하는 명시적인 규칙을 제공하지는 않습니다. 

The Definition (finally)

음함수 모델은 볼륨 상의 속성들에 대한 연속적인 수학적 표현입니다. 그것은 무한한 세부적인( fine ) 해상도를 가지고 있습니다. 이 모델로부터 눈에 보이는 서피스들을 생성하는 것은 개별적인 다음 단계입니다. 그리고 그것은 음함수 모델을 생성하는 것과는 별개입니다.

등급 셸을 블록 모델로부터 생성하는 시나리오를 다시 살펴 보죠. 위의 정의를 이용하면 두 가지 이유로 실패할 것입니다. 첫 번째로 그 모델은 삼차원 공간 상의 연속적인 등급이 아닌 개별적인 등급값을 가진 이산적인( discrete ) 점 집합입니다. 두 번째로 출력 서피스의 해상도는 원래 모델의 블록 크기에 의존합니다.

Isosurface Extraction

음함수 모델링은 일반적으로 세 부분으로 구별됩니다:

1. 적절한 형식으로 데이터를 조직하기.
2. 연속적인 볼륨 모델을 생성하기( 음함수 모델 ).
3. 모델에 포함된 하나 이상의 서피스들을 출력하기.

출력은 거의 항상 삼각화된( triangulated ) 메시나 와이어프레임( wireframe )입니다. 삼각형은 직선으로 구성되므로, 출력 와이어프레임은 모델링된 서피스의 근사치( approximation )입니다. 메시를 더 세부적으로 만들수록 ( 더 작은 삼각형으로 만들수록 ) 더 나은 근사치가 나오며 외형이 더 부드러워집니다. 메시의 크기는 외형과 계산 시간 사이의 타협점입니다.

서피스 점들을 생성하는 직접적인 방법이 존재하지 않기 때문에, 간접적인 수단에 의존해야 합니다. 가장 일반적인 기법들 중의 하나는 "마칭 큐브( marching cube )"라 불립니다.

그 원칙은 2D 원 예제에서 "마칭 스퀘어( marching square )" 를 사용해서 ( 가장 단순하게 ) 설명될 수 있습니다. 좌상단에 위치한 정사각형으로부터 시작해, 정사각형의 모서리( corner )에서 음함수를 평가합니다. 만약 모든 모서리들이 양수값을 반환한다면, 그 정사각형은 완전히 원 바깥쪽에 존재합니다. 마찬가지로, 모든 모서리가 음수값을 반환한다면, 그 정사각형은 완전히 원 안쪽에 존재합니다. 만약 일부 모서리는 원 바깥에 존재하고 일부 모서리는 원 안쪽에 존재한다면, 그 정사각형은 원과 겹쳐 있는 것이고, 겹치는 라인을 계산할 수 있습니다. 만약 정사각형과 동일한 크기의 그리드를 가진 영역을 다루고 있다면, 원을 근사계산하는 라인 세그먼트( segment ) 집합을 결과로 작업을 끝내게 될 것입니다. 정사각형이 더 작아질 수록, 더 많은 개수의 라인 세그먼트들이 생겨나고 그 결과는 더 부드러워집니다.

3D 문맥에서, 큐브의 크기는 최종 서피스의 해상도를 제어합니다. 아래에 있는 스크린샷( screenshot )에는 두 개의 드래곤이 있는데요, 같은 음함수 모델을 사용하고 있지만, 서피스들이 서로 다른 메시 크기를 사용해서 생성되었습니다.

Radial basis functions

음함수 모델링은 언제나( invariably ) Radial Basis Functions( RBF ) 와 연관되어 있습니다. 이것들은 분산된 데이터 보간 문제를 해결하는 가장 정확하고 안정적인 기법 중의 하나로 인식되고 있습니다.

기저 함수들은 수학적 레고( Lego )로 기술됩니다. 그것들은 기본적인 기능 빌딩 블록( functional building block )들의 집합인데, 그 블록들은 우리가 필요로 하는 기능들을 제공하기 위해 서로의 위쪽에 쌓일( stack )수 있습니다.

Radial 기저 함수는 거리에 기반해 값들을 생성하는 함수들의 그룹입니다. 그래서 특정 점에 가까워질 수록 더 많은 영향이 발생합니다. 가장 일반적인 유형들은 다음과 같습니다:

• Gaussian.
• Multiquadric.
• Inverse quadratic.
• Inverse multiquadric.
• Polyharmonic spline.

내 조사( survey )에 영향을 미친 것은 Grady Wright 가 2003 년에 작성한 논문입니다. 그는 RBF 개발이 초기에는 ( 1968 ) 자동화되고( automated ) 선입견없는( unbiased ) 등고선( contour ) 지도를 만들기 위해서 개발되었다고 언급했습니다. 

Summary

필자는 최근에 지질학자( geologist )들과 광산 기술자( engineer )들에게 음함수 모델에 대해서 어떻게 생각하는지에 대해 묻고 있습니다. 그 답변들은 다양했고 보통 명확하지 못했습니다. 자원 업계는 이 모델링 기술에 지난 10 년 동안 노출되어 왔습니다. 하지만 그 방법론은 더 오래전부터 존재했던 기하학적 프로세스들에서 채택되어 왔습니다. 우리는 음함수 모델링의 의미를 수집하기 위해 수학적 흔적을 따라야 합니다. 그렇게 하면, 명확한 정의가 보입니다. 그것은 볼륨 상의 수치적 속성들에 대한 연속적인 표현입니다. 그 모델은 x, y, z 항들에 대한 수학적 함수입니다. 보통 볼륨이 신발장 모양( shoe box shape )을 가지는게 편리합니다. 정의된 범위 내의 좌표계에서 xyz 위치를 삽입하면, 해당 위치의 속성값을 계산할 수 있습니다. 이것이 "연속적인 표현"이 의미하는 바입니다.

그 모델 자체를 가시화하는 직접적인 방법은 존재하지 않습니다. 이를 위해서는 추가적이고 독립적인 단계가 필요하며, 모델링되고 있는 속성들에 대한 하나 이상의 3D 등고이나 isosurface 들이 추출되는 것을 내포합니다.

우리 업계가 이 정의를 수용하는지 혹은 현재의 모호함을 계속 유지하게 되는지 여부는 여전히 남아 있습니다. 현재의 AusIMM "Mineral Resource and Ore Reserve Estimation -- Guide to Good Practice" 에는 "음함수 모델링" 에 대한 20 개가 넘는 참조들이 존재합니다. 이것은 이 방법론이 진지하게 수용되고 있음을 보여주며, 업계가 그 의미를 일관되게 이해하는 것이 더 중요해 집니다.

References

http://www.orefind.com/docs/orefind-research-papers-in-pdf/pigm_hr.pdf

http://www.unchainedgeometry.com/jbloom/dissertation.html

http://www.psych.mcgill.ca/misc/fda/ex-basis-a1.html

http://mathinsight.org/surface_defined_implicitly

http://www.wdv.com/Math/Calculus/Lecture01.pdf

http://amath.colorado.edu/faculty/fornberg/Docs/GradyWrightThesis.pdf

http://0fps.net/2012/07/10/smooth-voxel-terrain-part-1/