▲

GN⁺: 마이크로소프트보다 뛰어난 DirectX 셰이더 컴파일러 개발

 (devlog.hexops.com)
3P by neo 5달전 | favorite | 댓글 1개

DirectX 셰이더 컴파일러를 마이크로소프트보다 더 잘 만들기

  • Microsoft의 DirectX 셰이더 컴파일러의 복잡한 상태와 게임 개발자들에게 더 나은 경험을 제공하기 위한 노력에 대한 이야기.
  • Mach 엔진을 위해 Zig를 사용하여 WebGPU의 후속작인 sysgpu라는 실험적인 그래픽 API를 개발 중이며, Metal, Vulkan, Direct3D, OpenGL 백엔드를 지원할 예정.
  • Direct3D 12에서 사용할 수 있는 셰이더 프로그램을 컴파일해야 함.

DirectX의 간략한 역사

  • DirectX 그래픽 API는 HLSL을 셰이딩 언어로 사용.
  • 과거 Direct3D 11 이전에는 'FXC'라는 컴파일러가 사용되었으나, 유명하게 느리고 최적화가 덜 된 코드 생성으로 알려짐.

FXC는 더 이상 사용되지 않고, Direct3D 12와 함께 DXC가 등장

  • Direct3D 12와 Shader Model 6.0(SM6) 출시와 함께 Microsoft는 FXC를 폐기하고 'DXC'라는 새로운 컴파일러를 선보임.
  • DXC는 LLVM/Clang v3.7의 Microsoft 공식 포크이며, 변경 사항이 주석을 통해 명확하게 표시됨.

DirectX 드라이버가 아침으로 먹는 것: DXBC 또는 DXIL

  • HLSL이 Direct3D 프로그래밍의 선택 언어이지만, 실제로 GPU는 다양한 컴퓨트 아키텍처와 요구 사항을 가짐.
  • Microsoft는 개발자 친화적인 프론트엔드 API를 제공하고, 독립 하드웨어 벤더들이 드라이버를 작성하여 실제 하드웨어 ISA에 가장 가까운 것으로 변환.
  • DirectX 12와 Shader Model 6.0의 등장으로 DXBC 대신 DXIL이라는 새로운 포맷이 사용됨.

DXIL

  • DXIL은 현재 DirectX 12 드라이버 제조업체가 사용하는 공식 포맷.
  • 게임 개발자는 DXC 컴파일러를 사용하여 DXIL 바이트코드를 생성하고, 이를 그래픽 드라이버에 전달하여 GPU 하드웨어에서 실행될 실제 기계 코드로 변환.

Microsoft LLVM 포크 수정

  • Microsoft는 독립 드라이버 제조업체들이 특정한 LLVM 비트코드 포맷을 사용하는 것이 이상적이지 않다는 것을 인지하고 있으며, LLVM 포크 유지 관리가 즐겁지 않음을 인정.
  • Microsoft는 HLSL 컴파일 지원을 LLVM/Clang에 직접 통합하기 위한 작업을 시작함.

게임 개발자, WebGPU 등에 대한 도전

  • 그래픽 추상화 계층은 통합된 셰이딩 언어를 제공해야 하며, 현재 대부분의 WebGPU 구현은 HLSL을 DXBC 또는 DXIL로 컴파일하는 방식을 사용.

간단한 우회: SPIR-V

  • Vulkan/SPIR-V도 유사한 방식을 사용하며, SPIR-V가 최적화되었는지 여부는 GPU 제조업체가 결정.

dxcompiler.dll을 사용할지 말지?

  • WebGPU 런타임은 새로운 DXC HLSL 컴파일러를 사용할지, 성능과 코드 생성 품질이 떨어지는 공식적으로 폐기된 FXC 컴파일러를 사용할지 결정해야 함.

정적으로 링크할 수 없는 이유는?

  • Microsoft의 LLVM 포크는 정적 링크를 지원하지 않으며, 이는 빌드 시스템의 복잡성 때문임.

dxil.dll 소개 - DirectX 셰이더를 위한 독점적인 코드 서명 블롭

  • dxil.dll은 소스로부터 빌드되지 않으며, Microsoft의 '오픈 소스' 저장소에 종속적인 독점적인 플랫폼별 코드 블롭에 의존함.

플랫폼 지원 문제

  • Microsoft는 Windows(x86/arm)와 Linux(x86)용 dxil.dll만 배포하며, macOS나 Linux aarch64 바이너리는 제공하지 않음.

요약

  • DXC를 정적 라이브러리로 빌드할 수 없으며, 독점적인 코드 서명 블롭 때문에 LLVM 기능을 복원하는 것은 대규모 작업이 될 것임.
  • macOS나 arm Linux CI 파이프라인에서 크로스 플랫폼 게임을 위한 오프라인 셰이더 컴파일을 수행할 수 없음.

빌드 시스템 개선

  • CMake 빌드 시스템을 build.zig로 전환하여 단일 정적 라이브러리로 빌드하는 방법을 모색함.

동적 라이브러리 의존성 해결

  • DXC 코드베이스를 포크하고 C++ 코드를 수정하여 동적 라이브러리 의존성을 제거함.

독점적인 코드 서명 해결

  • dxil.dll에 의존하지 않고도 HLSL 셰이더를 컴파일할 수 있는 방법을 찾음.

결과

  • 독점적인 dxil.dll에 의존하지 않는 정적 바이너리의 dxcompiler 라이브러리와 dxc CLI를 제공함.
  • macOS, Linux, Windows용 바이너리를 CI 파이프라인에서 빌드함.

주의사항

  • 일부 바이너리는 아직 빌드되지 않거나 테스트되지 않았으며, HLSL이 아닌 Zig 자체를 셰이딩 언어로 사용할 계획임.

개인적인 메모

  • Stephen이라는 이름으로 정규직 기술 직업을 가진 후, Mach 엔진을 구축하기 위해 온라인에서 활동함.
  • FOSS에 뿌리를 두고 있으며, 도구를 소유하고 이를 통해 권한을 부여받아야 한다고 믿음.
  • Mach를 모두를 위해 구축하고 고품질 게임을 판매하여 생계를 유지하는 것이 꿈임.

읽어주셔서 감사합니다

  • machengine.org를 확인해보세요.
  • 개발을 지원하여 더 많은 작업을 할 수 있도록 고려해보세요.
  • Mach Discord 서버에 가입하세요.
  • GitHub에서 후원하세요.
  • machengine.org

GN⁺의 의견

  • 이 글에서 가장 중요한 것은 Microsoft의 DirectX 셰이더 컴파일러 DXC의 복잡성과 한계를 극복하고자 하는 개발자 커뮤니티의 노력임.
  • Mach 엔진 개발자가 Zig를 사용하여 DXC의 빌드 시스템을 개선하고, 독점적인 dxil.dll에 의존하지 않는 방식으로 HLSL 셰이더를 컴파일하는 새로운 접근 방식을 제시함으로써, 크로스 플랫폼 게임 개발에 중요한 기여를 함.
  • 이 글은 오픈 소스 소프트웨어의 중요성과 개발자가 자신의 도구를 소유하고 통제할 수 있어야 한다는 점을 강조하며, 기술 커뮤니티 내에서 협업과 혁신의 가치를 보여줌.
▲
neo 5달전  [-]
Hacker News 의견

  • 3D API 셰이더 컴파일의 복잡성에 대한 훌륭한 개요

    • 크로스-3D-API 셰이더 컴파일의 복잡한 문제에 대한 개요가 제공됨.
    • D3D와 마이크로소프트에 초점을 맞추고 있지만, 다른 3D API에서도 상황이 크게 나아지지 않음.
    • 예를 들어, 리눅스 호스트에서 메탈 셰이더를 크로스 컴파일할 수 없으며, macOS와 최근에는 윈도우즈에서만 가능함.
    • 만약 Mach 팀이 "Zig를 크로스-3D-API 셰이더 컴파일러로 사용"하는 것을 성공시키고, "Zig를 크로스 컴파일 툴체인으로 사용"하는 것처럼 원활하게 작동시킬 수 있다면, 이는 1995년 이후 컴퓨터 그래픽스에서 가장 큰 사건이 될 것임.

  • Godot와 관련된 문제

    • Direct3D 12 지원은 현재 Godot와 함께 배포되는 DirectX Shader Compiler의 독점적인 dxil.dll 라이브러리에 의존하고 있음.
    • 독점 소프트웨어를 배포하는 것은 Godot 프로젝트의 사명에 반함.

  • 추가적인 .dll 배포에 대한 논의

    • 많은 비디오 게임들이 이미 사용하는 독점 미들웨어(Bink, SpeedTree, PhysX 등)와 마찬가지로 추가적인 .dll을 배포하는 것이 필요하지 않음.
    • 대부분의 게임 런처(Steam, GOG, Epic 등)도 각각의 .DLL을 요구함.
    • 많은 게임들이 D3D11On12를 사용하며, 많은 출시된 게임들이 설치 파일 중에 dxil.dll을 포함하고 있음.
    • 코드 서명을 역공학하고 재구현한 작업은 특히 dxil.dll의 출력과 비트 단위로 동일하기 때문에 놀라운 일임.
    • 하지만, 더 쉬운 방법을 선호하는 사람들은 단순히 DLL을 배포하는 것을 선택할 수도 있음.

  • DXIL.dll 서명에 대한 질문

    • DXIL.dll이 수행하는 서명은 단순히 수정된 MD5인가?

  • LLVM의 코드 생성 계층과 인프라에 대한 DXC의 변화

    • DXC의 LLVM 포크는 LLVM의 코드 생성 계층과 인프라를 제거하거나 손상시킴.
    • 이 문제를 해결하고 손상된 LLVM 기능을 복구하는 것은 엄청난 작업이 될 것임.
    • 리소스 제약으로 인해 새로운 DXC 컴파일러에서 이 문제를 해결할 계획이 없음.
    • 미래에 Clang에서 DXBC 생성을 지원할 수도 있지만, 그 작업은 DXIL과 SPIR-V 생성을 먼저 지원하는 것에 초점을 맞추고 있어 몇 년 동안 시작되지 않을 것임.
    • 마이크로소프트 측에서 명확한 기대치를 설정하는 것에 대한 감사함을 표현함.

  • Mach 생태계에 대한 조언

    • 특히 mach-sysgpu에 대해 조사할 것을 권장함, 이는 WebGPU의 완전한 재구현으로, 주로 17세의 Ali Chraghi에 의해 작성됨.

  • SDL_gpu와 SDL3에 대한 논의

    • SDL 팀은 SDL3에서 출시될 SDL_gpu라는 새로운 셰이더 언어를 개발 중임.
    • 이는 게임에서 3D 그래픽과 관련하여 플랫폼 간 작업을 할 수 있는 방법을 제공할 것임.

  • Zig 언어의 활용

    • Zig 자체를 셰이딩 언어로 사용하는 것은 멋진 일임.
    • Zig는 진정한 언어로, 빌드 시스템이자 셰이딩 언어임.

  • 인프라 작업에 대한 감사의 표현

    • 이러한 종류의 인프라 작업이 많은 문을 열어주기 때문에 읽는 것이 기쁨임.

  • DXIL 발음에 대한 언급

    • DXIL은 "dixel"로 발음되며, "pixel"에서 'p'를 'd'로 바꾼 것과 같음.
답변달기