크로스 플랫폼 엔진 셰이더 컴파일 프로세스 분석

원문 링크 : https://zhuanlan.zhihu.com/p/56510874

跨平台引擎Shader编译流程分析

Background

원저작자가 Unity4에서 unity 2017/18 업그레이드에 참여하면서 엔진의 material system과 shader compile에 대한 생각을 기록한 포스팅이다.

Unity와 Unreal은 모두 크로스 플랫폼 게임 엔진이며 크로스 플랫폼의 기반에는 Shading Language와 렌더러가 포함된다. 셰이더 언어에서 Unity와 Unreal은 모두 널리 사용되는 HLSL을 선택했으며 필연적으로 크로스 플랫폼 셰이더 컴파일 체계를 필요로 하게 된다.

Differences in Shader compilation look UE4.22 the shader 
UE 4.22의 Shader compilation 프로세스는 아래와 같다.

UE4는 multi-API 호환 및 multi-device feature 호환을 위한 언어 변환을 MesaIR^[각주:1] 및 오픈 소스 Glslang 라이브러리와 결합된 SM5 레벨(Flex/Bison 툴 사용)을 구현.

셰이더 모델 6+의 기능(wave intrinsics, 명시적 8비트/16비트 데이터 유형)은 DXC/glslang 컴파일 환경에서만 사용할 수 있다. 물론 해당 기기가 지원하는지 여부는 확인이 필요하다. Metal 3는 이미 셰이더 동적 라이브러리를 지원한다.

Unity3D의 셰이더 컴파일 프로세스 살펴보기

Unity는 정교한 커널을 가진 작은 엔진이다. 에디터 수준에서 크로스 플랫폼 D3DCompiler.dll을 구현하고(Wine^{[각주:2][각주:3]} 의 PRELoader 참조), DXBC를 통해 멀티 플랫폼 셰이더 언어로 번역하고 일부 장치 기능도 지원하게 된다. D3DCompiler.dll은 X86 명령어이므로 해당 컴파일 솔루션은 모바일 장치에서 HLSL Compute Shader 컴파일을 지원하지 않는다.

2019년에 Microsoft는 LLVM^[각주:4]/Clang 에코시스템을 기반으로 하는 DirectXShaderCompiler를 오픈 소스로 제공했으며 Google은 SPIRV 생성기에 기여했으며 NVIDIA는 이 프로젝트에 RTX SPIRV 번역도 제공했으며 DXR/RTX도 홍보할 예정이다. 새로운 크로스 플랫폼 셰이더 컴파일 솔루션을 혁신하는 방법은 무엇일까?

현재 HLSL 컴파일을 지원하는 오픈 소스 솔루션은 주로 마이크로소프트의 DXC와 크로노스의 Glslang 프로젝트를 포함한다. DXC HLSL은 Microsoft와 Google에서 공식적으로 유지 관리하고 Glslang HLSL은 주로 Google에서 유지 관리한다.

NGFX solution

Differences between Unity and UE's material system 

Unity는 ShaderLab을 머티리얼에 적용하는 셰이더 제작 도구로 사용한다. ShaderLab은 RenderPass 및 RenderPipelineState를 설정할 수 있으며, 이는 Prebake PipelineState Object와 같은 향후 렌더링 확장에 유용하다. UE는 비쥬얼 스크립팅을 노드로써 표현하여 매터리얼을 제작하지만 둘 다 장단점이 있다. UE의 매터리얼 시스템은 아티스트가 사용하기에 더 유용하지만 제어가 쉽지 않고 쉽게  배열되기도 터지기도 하여 프로젝트 이터레이션의 진행 속도를 늦추게 된다. Unity의 ShaderLab의 배열과 조합은 (수동으로) 더 잘 제어되어 더 빠른 반복 속도를 제공한다.

UE의 기본 셰이더 수정은 또한 많은 수의 매터리얼을 다시 컴파일하는 경향이 있다. 물론 커스텀 셰이더 플러그인을 사용하거나 커스텀 셰이더 노드를 ShadingModel에 연결하여 해당 기능을 구현할 수도 있다.

The highest level of volume in the material Shader system 

NGFX Material system

Only Metal/Vulkan is supported, only binary IR translation is supported

통합 매터리얼 시스템을 설명하면, 셰이더 컴파일 프로세스에는 크로스-텍스트 언어 번역 프로세스가 없으므로 프로덕션 반복(여기에서는 컴파일)의 효율성이 크게 향상되며 장치는 런타임시 하드웨어 아키텍처 특성 및 드라이버에 따라 최상의 바이트 코드를 생성할 수 있다.

 

Thoughts on Shader Language 

현재 주류 실시간 렌더링 셰이더 텍스트 언어는 주로 HLSL, GLSL 및 Metal SL을 포함하여 모두 C와 같은 언어를 기반으로 개발되었으며 본질적으로 모듈식 셰이더 컴파일을 지원할 수 없다(프로그래밍 언어의 모듈식 지원은 컴파일 효율성을 어느 정도 향상시킨다). 자체 Falcor 렌더러에서 HLSL 구문을 기반으로 Slang 언어 을 더 잘 지원하기 위해 모듈화 및 하드웨어 기능 확장한다.

Metal Shading Language는 C++14를 기반으로 제작되었다. Metal 컴파일러에 의해 생성된 바이너리 셰이더는 실제로 표준 LLVM BitCode다. Metal의 내장 함수를 SPIRV의 내장 함수/클래스(metal::rendercommand/ metal::commandbuffer는 비교적 복잡함)에 매핑하면 Metal Bitcode를 SPIRV로 이진 변환을 쉽게 완료할 수 있다. Metal SL 컴파일러는 비공개 소스이지만 인터넷에는 오픈 소스 Metal SL 컴파일러(floor)를 구현한 사람들도 있다. 현재 Metal API는 Binary의 Shader 익스포트를를 제공하지 않는다. 바이너리 코드를 생성하려면 MacOS의 Metal 오프라인 컴파일러를 사용해야 하므로(로딩 속도를 향상시키기 위해 Shader Cache에 사용됨) floor는 주의할 가치가 있는 프로젝트일 수 있다.

CPU 및 GPU 코드( CircleLang )의 통합 컴파일 및 코드 생성을 달성하기 위해 LLVM Clang C++를 기반으로 고유한 구문을 추가하는 개발자도 있다.

https://www.circle-lang.org/

https://twitter.com/seanbax

최근 몇 년 동안 하드웨어 제조업체와 게임 엔진 제조업체 간의 긴밀한 협력을 기반으로 기본 하드웨어(WaveFront/Warp Level 병렬 프로그래밍, 정확한 데이터 유형 uint8/16...)의 프로그래밍 기능이 지속적으로 개방되었다. 셰이더 언어는 미래에 진화할까?

1. AST(Abstract Syntax Tree - 추상 구문 트리) : 이를 중간 언어라고 부르는 것은 다소 언어 남용. 이것은 Flex/Bison으로 parsing 직후의 GLSL 셰이더의 트리 표현.
   Mesa IR(Intermediate Representation) : HIR 및 GLSL IR이라고도 한다. A real Intermediate Language. AST에서 변환. 여기에 최적화, 링크 지원 등이 있다.
   NIR(New Intermediate Representation): 최근 추가된 새로운 중급 언어.
   https://blogs.igalia.com/apinheiro/2016/06/introducing-mesa-intermediate-representations-on-intel-drivers-with-a-practical-example/
   [본문으로]
2. Wine(원래 "Wine Is Not an Emulator"의 약어)은 리눅스, macOS, BSD와 같은 POSIX호환 운영체제에서 Windows 프로그램을 실행할 수 있는 호환성 레이어. 가상 머신이나 에뮬레이터와 같이 내부 Windows 로직을 시뮬레이션하는 대신 Wine은 Windows API 호출을 POSIX 시스템 호출로 즉시 대체한다. 다른 방식과 다르게 성능이나 메모리 문제가 적으며, Windows 프로그램을 데스크톱에 깔끔하게 통합할 수 있다. 나무위키 [본문으로]
3. Portable Operating System Interface + X. POSIX [본문으로]
4. Low Level Virtual Machine [본문으로]