- Die experimentelle Grafik-API sysgpu der Mach Engine benötigte Shader-Artefakte für Direct3D 12 und baute Microsoft DXC in einer statisch und plattformübergreifend leichter nutzbaren Form neu
- Direct3D 12s DXIL ähnelt eher nachbearbeitetem LLVM-Bitcode, wie ihn Microsofts LLVM/Clang-3.7-Fork ausgibt, und hängt strukturell stärker von der „tatsächlichen Compiler-Ausgabe“ als von einer Spezifikation ab
- WebGPU-nahe Runtimes wandeln WGSL normalerweise in HLSL um und erzeugen anschließend mit FXC oder DXC DXBC/DXIL, doch wegen des Distributionsaufwands von DXC wird häufig das alte und langsame FXC zur Standardeinstellung
- Bestehendes DXC ist schwer statisch zu linken, und die proprietäre Signatur-/Validierungs-Binary
dxil.dll wird vor allem für Windows und x86-Linux ausgeliefert, sodass Offline-DirectX-Shader-Kompilierung auf macOS oder in Arm-Linux-CI blockiert ist
mach-dxcompiler schreibt den CMake-Build als Zig-build.zig neu und entfernt die DLL-Abhängigkeit, um eine statische dxcompiler-Bibliothek und die dxc-CLI bereitzustellen; Einschränkungen bleiben jedoch bei MSVC ABI, musl-Tests, SPIR-V-Ausgabe und SM6.7-Unterstützung
Warum Mach DXC neu gebaut hat
- Die Mach Engine entwickelt in Zig eine experimentelle Grafik-API namens sysgpu und zielt auf Unterstützung für Metal-, Vulkan-, Direct3D- und OpenGL-Backends ab
- Beim Direct3D-12-Backend müssen Shader-Programme in ein Format kompiliert werden, das Direct3D 12 verarbeiten kann
- Dabei zeigte sich, dass Microsofts DirectX Shader Compiler DXC für Spieleentwickler eine komplexe und unbequeme Distributionserfahrung schafft
Der Wechsel der DirectX-Shader-Kompilierung von FXC zu DXC
- Die DirectX-Grafik-API verwendet HLSL als Shading Language
- Der HLSL-Compiler vor Direct3D 11 wurde FXC genannt, kurz für effects compiler
- FXC ist unter Spieleentwicklern als langsamer Compiler mit schlechter Codegenerierungsqualität bekannt
- Das kann sowohl bei der Shader-Kompiliergeschwindigkeit als auch bei der Laufzeitleistung nachteilig sein
- Mit Direct3D 12 und Shader Model 6.0 hat Microsoft das in Windows enthaltene FXC offiziell als deprecated markiert und DXC eingeführt, einen Fork auf Basis von LLVM/Clang v3.7
- DXC ist als Microsoft/DirectXShaderCompiler veröffentlicht, und Microsoft stellt auch vorgefertigte Binaries bereit
- In Microsofts LLVM-Fork sind HLSL-bezogene Änderungen mit den Kommentaren
// HLSL Change Start und // HLSL Change End markiert
DXBC und DXIL, die Direct3D-Treiber verarbeiten
- Da sich Hardwarearchitektur und Anforderungen je nach GPU-Hersteller unterscheiden, unterscheidet sich auch das native Binary, in dem HLSL letztlich ausgeführt wird, zwischen Intel-, NVIDIA- und AMD-GPUs
- Microsoft stellt Frontend-APIs wie Direct3D und HLSL bereit, während IHVs wie Intel, AMD und NVIDIA Treiber schreiben, die diese näher an die Hardware-ISA anbinden
- In DirectX 9 bis 11 verarbeiten Treiber DXBC
- Spieleentwickler kompilieren HLSL mit der
fxc.exe-CLI oder der d3dcompiler-API nach DXBC
- Der Treiber wandelt DXBC in ein Binary um, das auf der tatsächlichen GPU ausgeführt wird
- DXBC ist ein nicht öffentliches, proprietäres Format, das zwischen Microsoft und GPU-Treiberherstellern verwendet wurde
- Seit DirectX 12 und Shader Model 6.0 ist DXIL das offizielle Format, das DirectX-12-Treiberhersteller verarbeiten
- DXIL ähnelt LLVM-3.7-Bitcode nach Codegenerierung und Optimierungspässen, ergänzt um einen kleinen Custom-Container/Wrapper
- Die DXIL-Dokumentation ist weniger eine eigenständige Spezifikation, sondern hängt vom Bitcode ab, den Microsofts LLVM-3.7-Fork nach HLSL-Änderungen und Optimierungen tatsächlich ausgibt
Der verschwundene DXIR-Plan und der Wechsel zum LLVM-Upstream
- Microsoft hatte zu Zeiten von DirectX 12 und Shader Model 6.0 die Idee, DXIR als High-Level- und nicht optimiertes IR zu schaffen und DXC dieses in optimiertes DXIL absenken zu lassen
- 2021 wurden Formulierungen entfernt, die die Möglichkeit der Erstellung von DXIR andeuteten
- 2019 antwortete ein Microsoft-Mitarbeiter, dass es kaum Dokumentation zum Lowering-Prozess von DXIR nach DXIL gebe und DXIR kein offizielles Format sei, sondern eher dem ersten LLVM IR nach CodeGen entspreche
- 2023 erklärte ein Microsoft-Mitarbeiter, dass der LLVM-Fork von DXC große Teile der Codegenerierungsschicht und Infrastruktur von LLVM entfernt oder beschädigt habe
- Um DXBC-Erzeugung zu DXC hinzuzufügen, müssten defekte LLVM-Funktionen wiederhergestellt werden, und DXC werde sich damit nicht befassen
- Seit März 2022 schlägt Microsoft vor und arbeitet daran, HLSL-Kompilierunterstützung in den Hauptzweig von LLVM/Clang upstream zu bringen
- Dieser Umstellungsplan umfasst auch die Wiedereinführung von Unterstützung für Legacy LLVM v3.7 bitcode writing in modernem LLVM/Clang
WebGPU und der Distributionsaufwand von DXC für Game Engines
- Grafik-Abstraktionsschichten, die moderne Grafik-APIs wie Metal, Direct3D 12 und Vulkan vereinheitlichen wollen, benötigen auch eine einheitliche Shading Language
- Aktuelle WebGPU-Implementierungen zielen langfristig teils auf einen Pfad ab, der DXIL direkt ausgibt, tun dies in der Praxis aber meist nicht
- Der übliche WebGPU-Pfad sieht so aus
- Die Textsprache WGSL wird zur Laufzeit in HLSL umgewandelt
- HLSL wird mit einem HLSL-Compiler nach DXBC oder DXIL kompiliert
- Optimiertes DXBC/DXIL wird an den Grafiktreiber übergeben, der es in herstellerspezifische Zwischenrepräsentationen und Maschinencode umwandelt
- Auch Vulkan/SPIR-V ist so aufgebaut, dass der Treiber SPIR-V in ein natives Binary kompilieren muss
- Manche Treiber können annehmen, dass SPIR-V optimiert ist, das unterscheidet sich jedoch je nach Mobile- und Desktop-GPU
- Valves Fossilize hält einen Cache der tatsächlich vom Treiber kompilierten Binaries je Kombination aus GPU und Treiberversion vor
- Während DXIL immer LLVM-Bitcode nach Optimierungspässen ist, kann SPIR-V optimiert sein oder auch nicht
- Nur Apple Metal unterstützt eine API, die direkt in das native Binary-Format der tatsächlichen Zielhardware kompiliert
Die Optionen, die dxcompiler.dll und dxil.dll schaffen
- Da WebGPU-Runtimes die Umwandlung WGSL→HLSL→DXIL zur Laufzeit durchführen, müssen sie zwischen dem neuen DXC und dem alten FXC wählen
- Laut Bevy-Dokumentation ist FXC alt, langsam und nicht mehr gepflegt, benötigt aber keine zusätzliche DLL-Auslieferung
- DXC dagegen ist neu, schnell und gepflegt, erfordert aber, dass
dxcompiler.dll und dxil.dll zusammen mit der Anwendung ausgeliefert werden
- Dieses Auswahlproblem betrifft nicht nur Bevy, sondern auch Rust-Nutzer von
wgpu und Nutzer von Dawn WebGPU
- In der Folge machen viele Softwareprojekte das alte, langsame und nicht mehr gepflegte FXC zur Standardeinstellung
Warum statisches Linken von DXC schwierig ist
- Microsofts LLVM-Fork unterstützt kein statisches Linken
- Wenn man in den CMake-Dateien
SHARED auf STATIC ändert, entstehen etwa 15 statische Bibliotheken, doch die Link-Erfahrung ist schlechter als mit einer einzelnen Bibliothek
- Beim Versuch, CMake-
OBJECT-Bibliotheken zu verwenden, treten wegen Microsofts HLSL-Änderungen implizite wechselseitige Abhängigkeiten unabhängig von den logischen Abhängigkeiten zutage
- Teile der COM-Interface-Implementierung von DXC sind so entworfen, dass sie
dxcompiler.dll und dxil.dll als dynamische Bibliotheken laden und sich selbst aufrufen
- Allein durch das Ändern der Build-Einstellungen lässt sich nur schwer ein statisches DXC erstellen
Proprietäres dxil.dll und Shader-Signatur
dxil.dll wird beim Bauen von DirectXShaderCompiler aus dem Quellcode nicht erzeugt, ist in GitHub-Releases aber für Windows x86/Arm und Linux x86 enthalten- Laut D3D12 Shader Cache API specification akzeptiert D3D12 nur signierte Shader; wenn Laufzeitoptimierung oder Patching durchgeführt wird, muss der Shader erneut validiert und signiert werden
- In Preview-Releases von Shader Model 6.8 wird
dxil.dll/libdxil.so nicht bereitgestellt
- Das von diesem Compiler erzeugte, auf SM6.8 zielende DXIL ist nicht final und kann nicht validiert werden
- Deployment oder Ausführung auf Maschinen außerhalb des Developer Mode wird nicht unterstützt
- Ohne
dxil.dll werden Shader nicht signiert/validiert
- Nicht signierte/validierte Shader können auf Windows-Maschinen nicht ausgeführt werden, wenn diese nicht im Developer Mode sind
Offline-Kompilierung und Plattformbeschränkungen
- Mach möchte bei Bedarf die Distribution der schweren DXC-Abhängigkeiten vermeiden und Offline-Shader-Kompilierung durchführen
- Microsoft liefert
dxil.dll nur für Windows x86/Arm und Linux x86 aus
- Linux-aarch64-Binaries und macOS-Binaries werden nicht bereitgestellt
- Daher ist es nicht möglich, auf macOS plattformübergreifende Spiele-Builds für Windows zu erstellen oder in einer Arm-Linux-CI-Pipeline Offline-DirectX-Shader-Kompilierung durchzuführen
- Um die proprietäre Signatur-Binary auszuführen, ist eine Windows- oder x86_64-Linux-Maschine erforderlich
Was mach-dxcompiler geändert hat
- Das bestehende CMake-Build-System mit etwa 10,5k Zeilen wurde als Zig-
build.zig neu geschrieben
- Als Build-Ziele wurden nur die zwei Teile gewählt, die Nutzer hauptsächlich brauchen: die
dxcompiler.dll-Bibliothek und das dxc.exe-Binary für Offline-Kompilierung/Tests
- Das Ergebnis wurde auf etwa 1k Zeilen
build.zig-Logik reduziert
- Um die Struktur anzupassen, in der DXC die Existenz von
dxcompiler.dll und dxil.dll erwartet, wurde Microsofts Codebasis geforkt
- Der DLL-Entrypoint wird simuliert
- Die Funktion zur Ausgabe von aus der DLL stammenden Compiler-Versionsinformationen wird deaktiviert
- Das Laden von Funktionszeigern aus dynamischen Bibliotheken wird emuliert
mach-dxcompiler ist so aufgebaut, dass es nicht von dxil.dll abhängt- Auf einer macOS-Maschine können HLSL-Shader ohne proprietäres
dxil.dll kompiliert werden, sodass bytegenau identische Dateien zu DXIL-Bytecode entstehen, der auf normalen Windows-Maschinen läuft
Ergebnisse und Nutzung
- Das Release enthält vorgefertigte Binaries der statischen
dxcompiler-Bibliothek und der dxc-CLI
- Es gibt keine Abhängigkeit vom proprietären
dxil.dll
- Die in der CI-Pipeline gebauten Ziele sind
- macOS: Apple Silicon aarch64 und Intel x86_64
- Linux: musl und glibc, aarch64 und x86_64
- Windows: x86_64 und aarch64, einschließlich MinGW/GNU ABI
- Die Bibliothek stellt als Alternative zur bestehenden COM API eine kleine C API bereit
- Zig-Spieleentwickler können die Zig API des Repositorys verwenden; Beispiele finden sich im Test
src/main.zig
- Standardmäßig werden vorgefertigte Binaries heruntergeladen und verwendet
- Ein Build aus dem Quellcode ist im mach-dxcompiler-Repository nur mit
zig und git möglich; die angegebene Zig-Version ist erforderlich
git clone https://github.com/hexops/mach-dxcompiler
cd mach-dxcompiler/
zig build -Dfrom_source -Dtarget=aarch64-macos
zig build -Dfrom_source -Dtarget=x86_64-windows-gnu
zig build -Dfrom_source -Dtarget=x86_64-linux-gnu
Aktuelle Grenzen und Wartungsbedingungen
- Windows-MSVC ABI-Binaries werden derzeit wegen eines kleinen Bugs in den C-Bindings nicht gebaut
- Linux-musl-Binaries werden gebaut, sind aber noch nicht getestet
- Da die Mach Engine nicht HLSL, sondern Zig selbst als Shading Language verwenden will, wird Unterstützung für SPIR-V-Ausgabe nicht gebaut, und es gibt auch keine zusätzlichen Pläne dafür
- Derzeit gibt es keine Pläne für ein Update zur Unterstützung des kürzlich veröffentlichten SM6.7
- Teile des CMake-Build-Systems von LLVM sind noch nicht vollständig übertragen, und entsprechende Details verbleiben in
generated-include/
- Dieses Projekt existiert, um Machs Problem zu lösen, und derzeit bearbeitet eine einzelne Person die Issues
- Wenn ein besserer Weg gefunden wird, kann das Projekt deprecated werden
1 Kommentare
Meinungen auf Hacker News
Ein gut geschriebener Überblick darüber, wie chaotisch die Grundlagen der Shader-Kompilierung über mehrere 3D-APIs hinweg sind
Der Fokus liegt zwar auf D3D und Microsoft, aber andere 3D-APIs sind auch nicht wesentlich besser. Auf einem Linux-Host kann man zum Beispiel keine Metal-Shader cross-kompilieren; das geht nur auf macOS und auf vergleichsweise aktuellen Windows-Versionen
Wenn das Mach-Team seine Idee, Zig als Cross-3D-API-Shader-Compiler zu nutzen, so reibungslos hinbekommt wie „Zig als Cross-Compile-Toolchain“, könnte das die größte Sache in der Computergrafik seit etwa 1995 werden
Das hat auch mit Godot zu tun
Dort heißt es: „Der Grund, warum es optional gemacht wurde, ist, dass die Direct3D-12-Unterstützung derzeit davon abhängt, die proprietäre Bibliothek dxil.dll des DirectX Shader Compiler zusammen mit Godot auszuliefern, und die Verbreitung proprietärer Software der Mission des Godot-Projekts widerspricht“
https://godotengine.org/article/dev-snapshot-godot-4-3-dev-3...
Ich will, dass meine GPU, mein WLAN und Bluetooth funktionieren, also wäre es gut, wenn das standardmäßig angehakt wäre
Zu der Stelle „Es ist nicht nötig, eine zusätzliche .dll mit der Anwendung auszuliefern“: Viele Videospiele liefern proprietäre Middleware wie Bink, SpeedTree oder PhysX bereits genau so aus
Die meisten Launcher wie Steam, GOG oder Epic benötigen ebenfalls ihre eigenen .DLLs, und viele Spiele nutzen D3D11On12. Es gibt auch viele veröffentlichte Spiele, bei denen dxil.dll in der Liste der installierten Dateien enthalten ist
Deshalb frage ich mich ehrlich: Was ist das Problem daran, eine weitere DLL auszuliefern? Die Arbeit, die Codesignierung hier reverse-engineert und neu implementiert zu haben, ist großartig, besonders weil die Ausgabe bitgenau der von dxil.dll entspricht. Aber ich bin absurd faul und hätte vermutlich den einfacheren Weg gewählt, nämlich die DLL mitzuliefern
Die Mach-Engine könnte sie zum Beispiel verwenden, wenn sie einen Compiler baut, der Zig-Code in Shader für verschiedene Zielplattformen kompiliert, und Endnutzer könnten sie direkt innerhalb der Kernfunktionen von Mach nutzen, ohne zusätzliche Einrichtung oder Abhängigkeiten
Auch bei AAA-Spielen, und ebenso bei anderen Spielen und Software, kommen dadurch zusätzliche Abhängigkeiten hinzu, die außerhalb der eigenen Kontrolle kaputtgehen können. In einer früheren Firma mussten wir eine bestimmte Middleware nur als DLL und Bibliothek bekommen und dagegen linken; deshalb kosteten uns Visual-Studio-Upgrades mehr Aufwand, und wir mussten auch neue Versionen davon beziehen. Weil die Middleware-Firma ihrerseits das Upgrade nicht vorbereitet hatte, mussten wir sogar die QA für die Kompatibilität mit der neuen VS-Version mitübernehmen
Natürlich werden Updates nicht völlig reibungslos, nur weil man den Source Code hat, aber die Reibung wird deutlich geringer und man muss nicht auf andere warten. Neuere Visual-Studio-Versionen scheinen sich um Abwärtskompatibilität für binäre C++-Bibliotheken zu bemühen, aber ich halte das für nichts, worauf man sich langfristig verlassen kann
Außerdem gilt all das unter der Annahme, dass der Code auf derselben Plattform und für dasselbe Ziel bleibt. Irgendwann möchte man vielleicht andere Plattformen als Host oder Target unterstützen, und ohne Source Code kann das extrem schwierig oder unmöglich werden. Bei etwas Plattformspezifischem wie DXIL wirkt das vielleicht nicht wie ein großes Problem, aber der Artikel sagt ebenfalls, dass wegen des Binary-Blob-Charakters von DXIL das Vorabkompilieren von Shadern außerhalb der konkreten Windows- und Linux-Architekturen, für die Microsoft eine DLL bereitgestellt hat, unmöglich war
Ist das „Signieren“[1], das DXIL.dll durchführt, am Ende nur ein modifiziertes MD5?
1: https://github.com/hexops/DirectXShaderCompiler/blob/4190bb0...
Wer den Text bis dahin aufmerksam gelesen hat, konnte erkennen, dass es ein einfacher Hash oder etwas Ähnliches sein musste; im schlimmsten Fall hätte eben jemand das Assembly reverse-engineeren müssen.
Nach all der Mühe kann man Microsoft ruhig öffentlich kritisieren. Erst recht, wenn es um Open-Source-Code geht, den jeder Interessierte durchforsten und finden kann; danke an msk fürs Aufspüren.
https://github.com/baldurk/renderdoc/blob/4a620bb5a16b4de4e2...
Dieses Zitat[0] von Microsoft gefällt mir. Darin heißt es, dass der LLVM-Fork von DXC große Teile der Code-Generation-Schicht und Infrastruktur von LLVM entfernt oder kaputt gemacht hat; um die DXBC-Erzeugung in DXC zu unterstützen, wäre daher eine umfangreiche Arbeit nötig, um defekte LLVM-Funktionen zu reparieren und wiederherzustellen.
Wegen des großen Problemumfangs und begrenzter Teamressourcen werde man dieses Problem im neuen DXC-Compiler nicht lösen; künftig könne Clang zwar DXBC-Erzeugung unterstützen, aber da man sich vorerst auf die Unterstützung der DXIL- und SPIR-V-Erzeugung konzentriere, werde man damit wohl einige Jahre lang kaum anfangen können. Es ist erfrischend, klar gesagt zu bekommen, was nicht gemacht wird.
[0] https://github.com/microsoft/DirectXShaderCompiler/issues/57...
Es lohnt sich unbedingt, einen Blick auf das Mach-Ökosystem zu werfen. Insbesondere mach-sysgpu ist eine vollständige Neuimplementierung von WebGPU, und der Großteil davon wurde von dem 17-jährigen Ali Chraghi geschrieben.
Auf SDL-Seite wird für SDL3 eine von bestehenden Ansätzen abweichende Shader-Sprache in Form von SDL_gpu entwickelt. Ich beobachte das seit einiger Zeit aufmerksam, weil es ein plattformübergreifender Ansatz für 3D-Grafik in Spielen werden könnte.
Der Unterschied scheint eher zu sein, dass SDL_gpu noch in einem frühen Stadium ist, während WebGPU bereits zwei gute öffentliche Implementierungen hat.
Der weniger schmerzhafte Weg dürfte etwas wie HLSL/GLSL → SPIR-V ↔ DXIL sein, oder Shader direkt in SPIR-V zu schreiben.
Wine vkd3d scheint einen DXIL-→-SPIR-V-Konverter zu haben, und da es sich um eine viel einfachere Zwischensprache als bei High-Level-Shading-Language-Konvertern handelt, könnte das robuster sein.
Allerdings frage ich mich, ob es statt dieses LLVM-Monsters einen reinen, einfachen C99-basierten HLSL-→-DXIL-Compiler gibt, der ohne GCC oder Clang kompilierbar ist.
Um die Frage zu beantworten: nein. Die Umwandlung von HLSL nach DXIL liegt praktisch in Microsofts Hand, und es gab kaum Bemühungen, sich davon zu lösen.
Zig selbst als Shading Language zu verwenden, ist cool. Zig ist wirklich eine einzige Sprache für alles. Es ist auch ein Build-System und auch eine Shading Language!