DXC shader compiler integration

https://forum.unity.com/threads/unity-is-adding-a-new-dxc-hlsl-compiler-backend-option.1086272/

Official - Unity is adding a new "DXC" HLSL compiler backend option

 

TL;DR:

• Unity는 수년 동안 오래된 "FXC" HLSL 컴파일러를 사용했지만 FXC는 새로운 GPU 기능 지원을 받지 못하고 있으며 많은 컴파일 성능 문제가 있습니다. 새로운 "DXC" 셰이더 컴파일러를 옵션으로 추가하고 있습니다.
• DXC는 DX12, Vulkan 및 Metal에서 작동합니다.
• DX11 및 GL/ES는 아직 지원되지 않습니다.
• 평균 컴파일 시간은 이전 컴파일러보다 4배 빠릅니다.
• 컴파일된 코드 크기는 Vulkan에서 2배 더 작고 Metal에서는 거의 동일하며 DX12에서는 3배 더 큽니다.
• DXC는 일부 HLSL 언어 구성이 있는 FXC와 100% 호환되지 않습니다. 일부 셰이더는 컴파일을 위해 약간의 업데이트가 필요할 수 있습니다.

User guide

• Microsoft는 몇 년 전에 업데이트를 중단했습니다.
• FXC는 DX11/셰이더 모델 5.0 기능 세트로 제한됩니다(지원되지 않음: 레이 트레이싱 셰이더, 웨이브/simd 그룹 기능, 중심 좌표, 전체 FP16 지원 등).
• 셰이더 컴파일 시간 성능 문제가 있습니다. 가장 주목할 만한 점은 함수를 인라인할 때 느리고 큰 배열을 사용하는 모든 것을 컴파일할 때 매우 느립니다.
• FXC는 DX11 바이트코드로 컴파일되기 때문에 이를 Vulkan/Metal/OpenGL로 변환하면 분명히 "읽을 수 없는" 셰이더가 생성되고 때로는 최적이 아닌 셰이더도 생성됩니다.
• Mac/Linux에서 FXC를 사용하는 것은 정말 번거롭습니다.

 

Microsoft는 DX12(DXIL) 및 Vulkan(SPIR-V) 셰이더를 즉시 지원하는 오픈 소스 HLSL 컴파일러로 새로운 DXC(DirectXShaderCompiler)를 개발해 왔습니다. Targeting Metal은 SPIR-V + SPIRV-Cross를 거쳐야 가능하다.

• Unity에서 선택적 셰이더 컴파일러 백엔드로 DXC에 대한 지원을 추가하고 있습니다. DXC는 주로 두 가지 이점을 제공합니다.
• 최신 GPU 기능(예: 파동 함수)을 사용하는 셰이더를 작성할 수 있습니다.
• DXC는 종종 FXC보다 빠르게 코드를 컴파일합니다. 많은 셰이더에서 우리는 약 3-6배 더 빠르게 시도했습니다.
• 일부 셰이더 구성은 D3D가 아닌 플랫폼(예: Metal 또는 Vulkan)에서 더 빠른 셰이더를 생성할 수 있습니다.

그러나 문서에서 DXC가 아직 기본값이 아닌 이유를 확인하십시오.

 

셰이더 또는 셰이더 패스당 DXC를 활성화하는 방법

DXC는 #pragma use_dxc pragma를 HLSLPROGRAM/ENDHLSL 또는 CGPROGRAM/ENDCG 섹션에 배치하여 셰이더 패스별로 활성화할 수 있습니다.

pragma를 HLSLINCLUDE/ENDHLSL 또는 CGINCLUDE/ENDCG 섹션에 배치하여 .shader 파일의 모든 셰이더 패스에 대해 활성화할 수도 있습니다.

추가 플랫폼 인수(#pragma only_renderers에 사용되는 것과 유사한 인수)를 제공하여 그래픽 API별로 pragma를 활성화할 수도 있습니다. 예를 들어 #pragma use_dxc metal vulkan을 작성하면 Metal 및 Vulkan 그래픽 API에 대해서만 DXC가 활성화되고 D3D에는 활성화되지 않습니다. 인수가 제공되지 않으면 DXC를 지원하는 모든 플랫폼에서 DXC가 활성화됩니다.

참고: 여러 #pragma use_dxc가 동일한 파일에 있는 경우 마지막 항목만 사용됩니다. 이것은 예를 들어 다음과 같은 경우에 유용할 수 있습니다. DXC는 인수 없이 #pragma use_dxc가 있는 HLSLINCLUDE 섹션에서 지원되는 모든 플랫폼에 대해 활성화된 다음 두 번째 DXC pragma를 특정 셰이더 패스(HLSLPROGRAM 섹션)에 배치하여 해당 패스에 대해 다른 플랫폼으로 전역 DXC 설정을 재정의할 수 있습니다.

 

컴퓨트 셰이더에 DXC를 활성화하는 방법

동일한 #pragma use_dxc를 사용하여 컴퓨트 셰이더(.compute 확장자)에 대해 DXC를 활성화할 수도 있습니다. 여기서 pragma는 파일의 빈 줄에 배치할 수 있습니다. 일반 셰이더와 마찬가지로 여기서 pragma는 플랫폼 인수를 지원하고 파일의 마지막 pragma만 사용됩니다.

 

DXC가 꺼져 있는지 확인하는 방법

DXC로 작업할 때 특정 .shader 파일, 특정 패스 또는 특정 API에 대해서만 비활성화하려는 경우가 있습니다. 이것은 #pragma never_use_dxc로 달성할 수 있습니다. 이 pragma는 또한 API 인수를 사용하며 #pragma use_dxc가 해당 셰이더 스니펫에 있는지 여부에 관계없이 해당 API의 셰이더에서 DXC가 사용되지 않도록 합니다. API 인수가 제공되지 않으면 모든 API에 대해 DXC가 비활성화됩니다.

#pragma never_use_dxc는 #pragma use_dxc가 있을 수 있는 동일한 위치에 배치할 수 있으며 마찬가지로 특정 셰이더 스니펫에서 pragma의 마지막 인스턴스만 존중됩니다.

참고: #pragma never_use_dxc 다음에 #pragma use_dxc가 오는지는 중요하지 않습니다. 이러한 pragma는 개별적으로 구문 분석되며 특정 셰이더 스니펫에서 각각의 마지막 pragma만 사용됩니다.

 

#pragma require - Shader Model 6.x 기능 활성화

기존 #pragma require는 DXC가 허용하는 일부 새로운 기능에 해당하는 새로운 인수로 업데이트되었습니다. 이러한 인수의 임시 목록은 다음과 같습니다(단, 하드웨어에 대한 더 나은 매핑이 있는 경우 변경해야 할 수도 있음).

• WaveBasic - GL_KHR_shader_subgroup_basic에 해당하는 HLSL 내장 함수^[각주:1]
• WaveVote - GL_KHR_shader_subgroup_vote에 해당하는 HLSL 내장 함수
• WaveBallot - GL_KHR_shader_subgroup_ballot에 해당하는 HLSL 내장 함수
• WaveMath - GL_KHR_shader_subgroup_arithmetic에 해당하는 HLSL 내장 함수
• WaveMultiPrefix - SM 6.5 웨이브 내장 함수^[각주:2]
• QuadShuffle - GL_KHR_shader_subgroup_quad에 해당하는 HLSL 내장 함수
• Int64 - 셰이더의 64비트 정수 연산(원자 없음)
• Native16Bit - 산술 연산에 float16_t, int16_t, uint16_t 셰이더 유형을 사용합니다(절반은 자동으로 32비트 부동 소수점으로 변환되지 않음). 또한 상수 버퍼와 구조화된 버퍼에서 16비트 유형을 사용할 수 있습니다. Unity 2021.2a20에서 사용할 수 있습니다.
• Barycentrics - SV_Barycentrics 입력 시맨틱 및 GetAttributeAtVertex HLSL intrinsic^[각주:3]
• Int64BufferAtomics - DirectX SM 6.6과 함께 표준으로 제공되는 버퍼에 대한 64비트 정수 원자 연산. D3D12/Vulkan용 Unity 2022.1.0a16부터 사용 가능
• Int64GroupsharedAtomics - 그룹 공유 변수에 대한 선택적 SM 6.6 64비트 정수 원자. D3D12/Vulkan용 Unity 2022.1.0a16부터 사용 가능

이들 중 하나를 셰이더/패스에 추가하면 DX, Vulkan 및 Metal 플랫폼에서 해당 셰이더에 대해 DXC가 암시적으로 활성화됩니다. 이것은 #pragma never_use_dxc로 재정의할 수 있지만 FXC 컴파일러 백엔드에서 사용할 경우 컴파일하지 않을 가능성이 높습니다.^[각주:4]

이러한 기능을 사용하면 필요에 따라 DX 셰이더 대상 모델, Vulkan 버전/확장 및 Metal 버전이 조정됩니다.

WaveMatch 및 WaveMultiPrefix를 포함하며 Vulkan/Metal에는 해당 항목이 없습니다.

#pragma target

DXC(예: SM6.x)에서 사용할 수 있는 새로운 셰이더 모델 대상과 관련하여 새로운 #pragma 대상 인수를 노출하지 않기로 결정했습니다.

역사적으로 #pragma 대상(API 간의 기존 모델에 대한 미친 기능 대응 표 참조)을 유지하는 것은 고통이었으며 최신 그래픽 API 간의 기능이 필요하지 않기 때문에 D3D 외부에서는 이 개념이 더 이상 유용하지 않은 지점에 도달했다고 생각합니다. 선형 대응이 없으며 특정 GPU 모델에 존재하거나 누락될 수 있습니다. 이 때문에 #pragma require를 사용하여 셰이더에 새로운 기능을 노출했습니다.

이러한 이유로 #pragma target 5.0은 우리가 허용하는 가장 큰 pragma target으로 남을 것입니다. 그리고 SHADER_TARGET_AVAILABLE 매크로는 DXC로 컴파일할 때 50으로 정의된 상태로 유지됩니다.

Internal Codebase only: Making DXC를 기본 컴파일러로 만들기
누군가가 DXC를 더 철저하게 시도하려는 경우 Unity 코드 베이스에서 하나의 #define을 변경하고 편집기를 다시 컴파일하여 지원되는 API의 기본 컴파일러로 만들 수 있습니다. 이렇게 하려면 Tools/UnityShaderCompiler/Compiler/CompilerDXC.h에서 #define DXC_USAGE_MODE DXC_USAGE_MODE_OPT_IN을 #define DXC_USAGE_MODE DXC_USAGE_MODE_OPT_OUT으로 변경해야 합니다. 이렇게 하면 전용 섹션에 설명된 대로 #pragma never_use_dxc를 사용하여 특정 셰이더/API에 대해 DXC를 비활성화할 수 있습니다.

 

Status as of 2021.2 a10

Graphics API support

다음은 다양한 API에서 DXC 백엔드를 사용할 수 있는지 여부와 그 방법을 설명합니다.

DX11 - DX11에서 DXC 셰이더를 실행하면 작동하지 않습니다. 실제로 이는 셰이더가 단순히 그곳에서 실행되지 않고 일반적인 다음 하위 셰이더 -> 폴백 -> 핑크 오류 셰이더가 시작됨을 의미합니다. 이는 DXIL 바이트코드가 DX12에서만 허용되기 때문입니다. 대부분의 사용자가 여전히 주로 DX11을 대상으로 하며 DXC의 이점을 누릴 수 없기 때문에 이것은 큰 제한 사항입니다. 이에 접근하는 방법에는 여러 가지가 있습니다.

• DX11 및 DX12에 대한 별도의 컴파일된 셰이더 Blob은 전자의 경우 FXC를 사용하고 후자의 경우 DXC를 사용합니다. 단점: 우리는 여전히 FXC의 느린 컴파일 시간에 갇혀 있을 것입니다.
• DXC -> SPIR-V -> SPIRV-Cross -> HLSL -> FXC -> DX11 DXBC를 사용해 보십시오. 이상하게 들리겠지만 FXC가 관련된 마지막 부분은 이미 충분히 "평평화"/"최적화"된 HLSL 코드이고 FXC 컴파일 시간 느려짐은 더 이상 문제가 되지 않을 것입니다.
• 수행할 수 있는 경우(예: 셰이더가 셰이더 모델 6.x 기능을 사용하지 않는다고 가정)에 대해 DX12 DXIL -> DX11 DXBC 변환기를 작성해 보십시오.

 

DX12 - 몇 가지 주의 사항과 함께 작동합니다.

• Windows 편집기를 사용하는 경우 DX12용 DXC 셰이더만 컴파일할 수 있습니다. 이는 DX12 셰이더에 필요한 코드 서명 및 반영이 기본 dxil.dll Windows DLL에만 존재하기 때문입니다.
• 에디터 씬보기 와이어프레임이 DXC로 컴파일된 DX12 셰이더에서 작동하지 않음(2021.2.0a19에서 수정됨)
• 초기 버전의 Windows 10/DX12에는 DXIL 지원이 없었습니다. 따라서 DX12가 일반적으로 작동하지만 DXC/DXIL 셰이더를 허용하지 않는 상황이 발생할 수 있습니다. 이는 DXIL이 Windows 10 버전 1703(2017년 4월)부터만 출시되었기 때문입니다.

 

Vulkan - 작동합니다. 내부적으로 DXC는 SPIR-V를 내보냅니다. Unity 런타임 기대치에 맞추기 위해 일부 리소스 재매핑도 수행합니다. 가장 큰 주의 사항은 현재 DirectX와의 리소스 메모리 레이아웃 호환성을 유지하기 위해 VK_EXT_scalar_block_layout 확장이 필요하다는 것입니다(이 확장에 대한 지원이 증가하고 있지만 아직 보편적이지는 않음).

 

Metal - 작동합니다(2021.2a20부터 시작하는 테셀레이션 셰이더). Vulkan과 유사하게 DXC는 SPIR-V를 방출한 다음 SPIRV-Cross를 사용하여 Metal Shading Language로 변환합니다.

 

OpenGL 및 GLES - 작동하지 않습니다. OpenGL에서 DXC를 사용하려고 하면 항상 이전 FXC+HLSLcc 컴파일러로 돌아갑니다. 우리는 SPIRV-Cross를 사용하여 OpenGL을 대상으로 하는 실행 가능성을 조사할 계획입니다.

 

SRP support

• HDRP 및 URP 버전 11.x 셰이더가 DXC에서 작동하도록 수정되었습니다.
• ShaderGraph - 현재로서는 ShaderGraph에 대해 DXC를 활성화할 수 있는 방법이 없습니다(셰이더 pragma를 거기에 추가할 수 없기 때문에). DXC 고유의 새로운 기능/내재 기능은 현재 해당 그래프 노드가 추가되지 않았습니다.

 

DXC vs FXC

Compile time and shader size

다양한(내장, HDRP, URP, 후처리) 셰이더에서 셰이더 컴파일 시간과 결과 데이터 크기를 측정했습니다. 다음은 전체 스프레드시트입니다.

컴파일 시간: DXC는 일반적으로 이전 백엔드보다 훨씬 빠릅니다. 백엔드에 따라 HDRP 템플릿을 빌드할 때 ~3.2~6.8^[각주:5]배 더 빠릅니다.

셰이더 크기(압축 후):

• DX12 - HDRP 출력은 최대 1.7배 더 큽니다(압축 전 FXC 출력의 0.75에 불과하지만 DXIL은 DXBC보다 압축률이 낮습니다). URP 출력은 DXC로 4배 더 큽니다...
• Metal - 출력 크기는 비슷하지만 URP 템플릿의 경우 약간 더 큽니다(1.35배 더 큼).
• Vulkan - 출력 크기가 이전 컴파일러보다 약 2배 작습니다.

 

셰이더 차이점/문제

DXC 컴파일러는 FXC에서 허용하는 HLSL 구문과 100% 역호환되지 않습니다. 대부분의 HLSL 구성은 이전과 동일하게 컴파일되고 작동하지만 전부는 아닙니다. 일부 기존 셰이더는 DXC와 함께 작동하도록 편집해야 할 수 있습니다.
공식 DXC 문서에는 FXC와 DXC의 몇 가지 차이점이 나열되어 있습니다.
FXC에서 DXC로 셰이더 포팅 우리가 발견한 주요 차이점 목록은 다음과 같습니다.

1. HLSL 출력 시맨틱을 보다 엄격하게 사용해야 합니다. 예를 들어 픽셀 셰이더의 출력은 COLOR가 아닌 SV_Target이어야 합니다. 또한 꼭짓점/도메인/기하학 단계에는 시각적 개체를 생성하기 위해 SV_Position 출력 의미 체계(POSITION 의미 체계가 더 이상 작동하지 않음)가 있어야 합니다.
2. 무음 벡터 유형 절단을 허용하지 않음: float a = uv.xy
3. Float VFACE 픽셀 셰이더 입력 시맨틱은 더 이상 지원되지 않습니다. bool SV_IsFrontFace를 사용해야 합니다.
4. 상수 버퍼 전역에 대한 쓰기를 허용하지 않습니다. 여기서 셰이더는 임시 변수를 사용하는 대신 전역 변수에 쓰고 나중에 수정된 값을 읽습니다. 예를 들어 Unity의 내장 인스턴스 입자 셰이더는 이에 의존합니다. 현재 우리는 그들을 위해 DXC를 비활성화합니다.
5. 픽셀 셰이더에서 쓰기 가능한 리소스(RWTexture, RWBuffer, RWStructuredBuffer 등과 같은 "UAV")를 사용하려면 C# SetRandomWriteTarget에서 사용하는 바인딩 인덱스와 일치하는 N과 함께 ": register(uN)" 주석을 사용하여 바인딩 인덱스를 표시해야 합니다. 이는 FXC에서도 기술적으로 필요했지만, 대부분의 경우 "픽셀 셰이더 색상 출력 수 + 1"인 "가장 논리적인" 바인딩 인덱스를 자동으로 할당했습니다. DXC는 더 이상 그렇게 하지 않습니다.
6. Texture2DMS<유형>을 사용할 수 없습니다. Texture2DMS<유형, 샘플>을 사용해야 합니다.
7. 셰이더 함수 진입점 인수로 전달된 리소스를 지원하지 않습니다. float4 frag(StructuredBuffer<float4> buffer) : SV_Target이 작동하지 않습니다.
8. 사용되지 않은 변수는 Metal/Vulkan/OpenGL을 대상으로 할 때 전역 상수 버퍼에서 제거되지 않습니다.
9. DXC를 사용하는 atan2(0,0)은 PI/2가 될 수 있지만 FXC를 사용하면 NaN이 됩니다. 둘 다 "정의되지 않음"이므로 정확합니다.
10. round() 문제: FXC는 상수 0.5를 1.0으로 반올림하는 데 사용되지만 변수에서 오는 값 0.5는 0.0으로 줄입니다. DXC는 지속적으로 둘 다 0.0으로 반올림합니다. 그러나 예를 들어 Metal은 장치에 따라 0.5를 0.0 또는 1.0으로 반올림합니다.
11. FXC+HLSLcc 컴파일러 스택은 하위 통과 입력(Vulkan)/프레임 버퍼 가져오기(Metal)를 입력 조각 인수로 지원했습니다. 이는 DXC에서 지원되지 않습니다. 하위 패스 입력을 수행하는 유일한 방법은 UNITY_DECLARE_FRAMEBUFFER_INPUT_<type>, UNITY_READ_FRAMEBUFFER_INPUT_<type>을 통하는 것입니다.
12. DXC는 아직 Metal에서 HLSL CalculateLevelOfDetail 함수를 지원하지 않습니다.

Why is DXC not the default compiler?

The DXC backend still has some limitations which prevent us from making it default. These are (roughly in the order from most important to least important):

1. Does not work for DX11 - the new DXIL shader bytecode format is only accepted by DX12 (DX11 only accepts the FXC generated DXBC bytecode, while DX12 accepts both DXBC and DXIL). And due to the fact that there is currently no separation between DX11 and DX12 shader data (as it used to be identical with FXC). The latter means that we cannot just use DXC for DX12 and FXC for DX11 until their bytecode is split up.
2. Vulkan requires VK_EXT_scalar_block_layout device extension, which is not yet universally supported. We require this for DXC as we rely on forcing DX memory layout with -fvk-use-dx-layout compiler flag on Vulkan/Metal to maintain StructuredBuffer memory layout compatibility between APIs (the old backend would achieve the same by sidestepping the issue and making all structured buffers contain only UINT for Vulkan/Metal and relying on bitcasts to and from memory to achieve layout compatibility between APIs).
3. DXC Vulkan support for mobile is not yet sufficiently tested
4. Reduced precision scalar/vector/sampler types are not yet supported and thus DXC backends always run at full precision (e.g. Sampler2D_half, half and half4, etc. will have full float precision)
5. Cannot compile for DX12 from Mac/Linux.
6. ShaderGraph can’t use DXC since it does not expose “pragma require”.
7. Metal tessellation is not implemented yet (done in 2021.2a20).
8. DXC cannot be used for instanced particle shaders as they rely on legacy HLSL syntax of writing to constant buffers (it’s just syntactic sugar, the buffers are not actually written to) so #pragma never_use_dxc is required to not break those.
9. DXC still has quite a few bugs which affect our shader codebase; see the list of open DXC issues below.

iOS using base_instance will currently not compile with DXC (fixed in  2021.2a20)

 

Our open upstream DXC issues

1. [SPIR-V] SV_Position can no longer be declared to be min10float4, min16float4, float16_t4 or half4 after fix to issue 3736 (works with DXIL)
2. GLSL: High precision ops involving constants get implicitly demoted to mediump during translation
3. [SPIR-V] Resources declared in cbuffer scope result in validation errors instead of being moved out (works with FXC)
4. [SPIR-V] Trying to "write" to uniforms using the -Gec backwards compatibility mode produces invalid codegen (works with DXIL backend)
5. [SPIR-V] Using bool types or their arrays in Hull and Domain stage IO fails compilation (works with DXIL backend)
6. [SPIR-V] Patch constant function does not support out parameters (works with DXIL backend)
7. No warning/error when SV_Position semantic is missing from Vert/Domain/Geom output and POSITION is used instead
8. [SPIR-V] Omitting outputtopology Hull entry point attribute does not get caught (is caught by DXIL backend)
9. [SPIR-V] No error when Hull and patchconstantfunc input point counts don't match
10. [SPIR-V] Reapeated SV_DomainLocation semantics don't produce an error and can crash the compiler (works with the DXIL backend)
11. [SPIR-V] Using very large vert/hull/domain IO produce a silent compiler crash (works with DXIL backend)
12. [SPIR-V] Zero as control point template argument for InputPatch Hull input fails validation and asks to report a bug
13. [SPIR-V] [outputcontrolpoints(0)] or missing outputcontrolpoints Hull stage attribute crash the compiler (works with DXIL backend)
14. Some compile time const expressions can't be used to specify const array lengths (works with FXC)
15. DXC's preprocessor allows missing macro arguments and produces invalid output with -flegacy-macro-expansion (different from FXC)
16. Relative includes are handled differently from FXC - directories of previously included source files get searched
17. Using Texture2D<bool*>.Load results in validation errors with both DXIL and SPIR-V backends (not with FXC)
18. [SPIR-V] Arrays of empty structs in cbuffers produce validation errors when optimizations are disabled (asks to file a bug)
19. [SPIR-V] Silent compiler crash when using GetAttributeAtVertex
20. [SPIR-V] Crash when result of dot4add_u8packed or dot4add_i8packed is operated on by a literal
21. Plans to support DXIL reflection on non-windows platforms?
22. Array in cbuffer reported as unused by reflection
23. "error: reference to 'i' is ambiguous" where loop scoped variable should take priority. Other compilers have no issues

To get fixes for these issues into Unity after they’re done it’s required to update our fork of DXC by merging in the fixed upstream master and then adding the updated DXC library to the Unity repo for all the platforms and adding/fixing up any unit tests.

Closed upstream DXC/SPIRV-Cross issues

1. [SPIR-V] Using SV_Target and SV_Target0 in the same PS fails validation instead of printing an error
2. [SPIR-V] Structs with doubles violate 8B alignment requirement and fail validation when using dx layout
3. [SPIR-V] SV_ClipDistance variable not allowed to be of array type (works with DXIL backend and FXC)
4. [SPIR-V] Matrices in constant buffers are unnecessarily padded when using DirectX memory layout
5. [SPIR-V] Compiler does not complain about writing to read only StructuredBuffer<> resources (DXIL backend does)
6. [SPIR-V] Writing to a read only Buffer<> resource produces validation errors (asks to report a bug)
7. [SPIR-V] Declaring SV_POSITION not as float4 produces validation errors and asks to report a bug
8. [SPIR-V] Using RWTexture2D or RWBuffer with min precision types crashes the compiler
9. [SPIR-V] Reading from a RWTexture2D with a min precision template argument produces validation errors (good with DXIL backend or FXC)
10. MSL: gl_Position is undetectable in tessellation stage IO using the SPIRV-Cross reflection API
11. Using legacy VFACE semantic does not work but compiler error is not printed (affects both DXIL and SPIR-V backends)
12. Reflection info says Texture2DMS<float4> is not multisampled unless explicit sample count is provided (different from FXC and SPIR-V backend)
13. Silent crash or validation error when SV_InnerCoverage semantic is assigned to a float parameter instead of uint
14. [DXIL] Decorating CS float argument with SV_DispatchThreadID semantic crashes the compiler (float2, float3 and float4 works)
15. [SPIR-V] Assigning SV_DispatchThreadID to a float argument causes validation errors (does not happen with DXIL backend)
16. MSL: No way to set msl_options.ios_support_base_vertex_instance from the C API
17. [SPIR-V] Forward declaring a function inside another function causes a compiler crash
18. [SPIR-V] Reading or writing a struct's member from a derived struct's method causes SPIR-V codegen errors
19. Can't have resources in entry point parameter list (works with FXC) (Rejected)
20. [SPIR-V] Crash on assertion when compiling shaders containing SubpassInputs and global struct instances with resource only members
21. [SPIR-V] Global struct variables containing only resources fail validation with '-O0' optimization level
22. Optimized DXIL doesn't work correctly when memory barriers are placed in between identical conditions
23. Invalid float4 to float assignment in codegen when using arrays of scalars (int[], float[]) in constant buffer
24. MSL: Why do names starting with '_' followed by a digit e.g. "_1PixelColor" get changed to _m<num>?
25. MSL: SubgroupSize becomes [[thread_execution_width]] instead of [[threads_per_simdgroup]] in compute shaders
26. [SPIR-V] Silent crash when using any WaveMultiPrefix* intrinsic with first arg of type uint*
27. MSL: RWBuffer<uint> is translated into a texture2d and buffer of atomic_int even though SPIRV-Cross can tell the original type
28. [MSL] SPIRV-Cross assumes std140 layout and fails with SPIR-V generated with DXC's -fvk-use-dx-layout option
29. [Question] How to tell which UBO members are actually used with the reflection API?
30. [SPIR-V] global struct variables containing only resources get placed in uniform buffer

NB: Not all of these have been integrated into our DXC/SPIRV-Cross fork repositories yet so these issues are still present when using DXC with Unity (the ones already fixed in Unity are striked out)

1. 해당 HLSL 및 MSL 고유 기능이 있는 이 Vulkan 명령어 세트의 하위 집합(그래픽 API 간 새 고유 기능 매핑 참조) [본문으로]
2. WaveMatch 및 WaveMultiPrefix를 포함하며 Vulkan/Metal에는 해당 항목이 없습니다. [본문으로]
3. GetAttributeAtVertex는 현재 SPIR-V 백엔드와 충돌을 일으킵니다. [본문으로]
4. FXC의 경우 HDRP 셰이더에서 WaveReadLaneFirst와 같은 일부 내장 기능을 에뮬레이션하기 위해 함수 오버로딩을 사용하지만 이러한 오버로드는 DXC SPIR-V 백엔드에서 허용되지 않습니다. 실제 내장 기능으로 해석되고 컴파일 중 불충분한 Vulkan 버전 세트로 인해 오류가 발생하기 때문입니다. (적절한 #pragma require가 설정된 경우에만 버전이 올라갑니다.) [본문으로]
5. HDRP 프로젝트 템플릿에서 가장 긴 상위 20개까지의 컴파일 셰이더에 대한 타이밍입니다. [본문으로]