Entwicklung eines besseren DirectX-Shader-Compilers als Microsoft

Einen DirectX-Shader-Compiler bauen, der besser ist als der von Microsoft

• Eine Geschichte über den komplexen Zustand von Microsofts DirectX-Shader-Compiler und die Bemühungen, Spieleentwicklern eine bessere Erfahrung zu bieten.
• Für die Mach-Engine wird mit Zig an einer experimentellen Grafik-API namens sysgpu gearbeitet, einem Nachfolger von WebGPU, die Metal-, Vulkan-, Direct3D- und OpenGL-Backends unterstützen soll.
• Shader-Programme müssen kompiliert werden, damit sie unter Direct3D 12 verwendet werden können.

Eine kurze Geschichte von DirectX

• Die Grafik-API DirectX verwendet HLSL als Shading-Sprache.
• In der Vergangenheit, vor Direct3D 11, wurde ein Compiler namens FXC verwendet, der berüchtigt langsam war und für die Erzeugung nur wenig optimierten Codes bekannt war.

FXC wird nicht mehr verwendet, und mit Direct3D 12 kam DXC

• Mit der Veröffentlichung von Direct3D 12 und Shader Model 6.0 (SM6) stellte Microsoft FXC ein und präsentierte einen neuen Compiler namens DXC.
• DXC ist ein offizieller Microsoft-Fork von LLVM/Clang v3.7, wobei Änderungen durch Kommentare klar gekennzeichnet sind.

Was DirectX-Treiber zum Frühstück essen: DXBC oder DXIL

• HLSL ist zwar die bevorzugte Sprache für die Direct3D-Programmierung, tatsächlich verfügen GPUs jedoch über unterschiedliche Compute-Architekturen und Anforderungen.
• Microsoft stellt eine entwicklerfreundliche Frontend-API bereit, und unabhängige Hardwarehersteller schreiben Treiber, die den Code in etwas umwandeln, das der tatsächlichen Hardware-ISA möglichst nahekommt.
• Mit dem Aufkommen von DirectX 12 und Shader Model 6.0 wird anstelle von DXBC ein neues Format namens DXIL verwendet.

DXIL

• DXIL ist derzeit das offizielle Format, das von Herstellern von DirectX-12-Treibern verwendet wird.
• Spieleentwickler erzeugen mit dem DXC-Compiler DXIL-Bytecode und übergeben ihn an den Grafiktreiber, der ihn in den tatsächlichen Maschinencode umwandelt, der auf der GPU-Hardware ausgeführt wird.

Änderungen am Microsoft-LLVM-Fork

• Microsoft ist sich bewusst, dass es nicht ideal ist, wenn unabhängige Treiberhersteller ein bestimmtes LLVM-Bitcode-Format verwenden müssen, und räumt ein, dass die Pflege des LLVM-Forks keine angenehme Aufgabe ist.
• Microsoft hat damit begonnen, die Unterstützung für die HLSL-Kompilierung direkt in LLVM/Clang zu integrieren.

Herausforderungen für Spieleentwickler, WebGPU und mehr

• Grafik-Abstraktionsschichten müssen eine einheitliche Shading-Sprache bereitstellen, und die meisten aktuellen WebGPU-Implementierungen kompilieren HLSL zu DXBC oder DXIL.

Ein einfacher Umweg: SPIR-V

• Vulkan/SPIR-V verwendet einen ähnlichen Ansatz, und ob SPIR-V optimiert wird, entscheiden die GPU-Hersteller.

dxcompiler.dll verwenden oder nicht?

• Eine WebGPU-Runtime muss entscheiden, ob sie den neuen HLSL-Compiler DXC verwendet oder den offiziell eingestellten FXC-Compiler, dessen Performance und Qualität der Codeerzeugung schlechter sind.

Warum nicht statisch linken?

• Microsofts LLVM-Fork unterstützt kein statisches Linken, was auf die Komplexität des Build-Systems zurückzuführen ist.

Einführung von dxil.dll – ein proprietärer Code-Signing-Blob für DirectX-Shader

• dxil.dll wird nicht aus den Quellen gebaut, sondern hängt von einem proprietären plattformspezifischen Code-Blob ab, der in Microsofts „Open-Source“-Repository eingebunden ist.

Probleme bei der Plattformunterstützung

• Microsoft verteilt dxil.dll nur für Windows (x86/arm) und Linux (x86), bietet aber keine Binärdateien für macOS oder Linux aarch64 an.

Zusammenfassung

• DXC lässt sich nicht als statische Bibliothek bauen, und wegen des proprietären Code-Signing-Blobs wäre es eine große Aufgabe, die LLVM-Funktionalität wiederherzustellen.
• Offline-Shader-Kompilierung für plattformübergreifende Spiele ist in macOS- oder ARM-Linux-CI-Pipelines nicht möglich.

Verbesserung des Build-Systems

• Es wird untersucht, wie das CMake-Build-System auf build.zig umgestellt werden kann, um auf eine einzelne statische Bibliothek zu bauen.

Lösung der Abhängigkeiten von dynamischen Bibliotheken

• Die DXC-Codebasis wurde geforkt und der C++-Code angepasst, um die Abhängigkeiten von dynamischen Bibliotheken zu entfernen.

Lösung für die proprietäre Code-Signierung

• Es wurde ein Weg gefunden, HLSL-Shader zu kompilieren, ohne von dxil.dll abhängig zu sein.

Ergebnis

• Es werden eine dxcompiler-Bibliothek und eine dxc-CLI als statische Binärdateien bereitgestellt, die nicht von der proprietären dxil.dll abhängen.
• Binärdateien für macOS, Linux und Windows werden in CI-Pipelines gebaut.

Hinweise

• Einige Binärdateien sind noch nicht gebaut oder getestet, und langfristig ist geplant, anstelle von HLSL Zig selbst als Shading-Sprache zu verwenden.

Persönliche Notiz

• Unter dem Namen Stephen ist der Autor online aktiv, nachdem er eine technische Vollzeitstelle angenommen hat, um die Mach-Engine aufzubauen.
• Er ist in FOSS verwurzelt und glaubt daran, dass man seine Werkzeuge besitzen und dadurch handlungsfähig werden sollte.
• Sein Traum ist es, Mach für alle zu bauen und den Lebensunterhalt durch den Verkauf hochwertiger Spiele zu verdienen.

Danke fürs Lesen

• Schauen Sie bei machengine.org vorbei.
• Erwägen Sie, die Entwicklung zu unterstützen, damit mehr Arbeit möglich wird.
• Treten Sie dem Mach-Discord-Server bei.
• Unterstützen Sie das Projekt auf GitHub.
• machengine.org

Meinung von GN⁺

• Das Wichtigste an diesem Artikel ist das Bemühen der Entwickler-Community, die Komplexität und Grenzen von Microsofts DirectX-Shader-Compiler DXC zu überwinden.
• Der Entwickler der Mach-Engine leistet mit Zig einen wichtigen Beitrag zur plattformübergreifenden Spieleentwicklung, indem er das Build-System von DXC verbessert und einen neuen Ansatz vorstellt, HLSL-Shader ohne Abhängigkeit von der proprietären dxil.dll zu kompilieren.
• Der Artikel unterstreicht die Bedeutung von Open-Source-Software und dass Entwickler ihre Werkzeuge besitzen und kontrollieren können sollten, und zeigt den Wert von Zusammenarbeit und Innovation in der technischen Community.

[GN⁺]

Hacker-News-Kommentare

• Ein hervorragender Überblick über die Komplexität der Shader-Kompilierung für 3D-APIs

  • Es wird ein Überblick über das komplexe Problem der API-übergreifenden Shader-Kompilierung für 3D-APIs gegeben.
  • Der Fokus liegt zwar auf D3D und Microsoft, aber bei anderen 3D-APIs ist die Lage auch nicht wesentlich besser.
  • Beispielsweise lassen sich Metal-Shader nicht von einem Linux-Host aus cross-kompilieren; möglich ist das nur auf macOS und seit Kurzem auch auf Windows.
  • Wenn es dem Mach-Team gelingt, „Zig als API-übergreifenden Shader-Compiler für 3D-APIs zu verwenden“ und das so nahtlos funktioniert wie „Zig als Cross-Compile-Toolchain zu verwenden“, dann wäre das das größte Ereignis in der Computergrafik seit 1995.

• Probleme im Zusammenhang mit Godot

  • Die Unterstützung für Direct3D 12 hängt derzeit von der proprietären Bibliothek dxil.dll des DirectX Shader Compiler ab, die zusammen mit Godot ausgeliefert wird.
  • Die Verbreitung proprietärer Software widerspricht der Mission des Godot-Projekts.

• Diskussion über die zusätzliche Verteilung von .dll-Dateien

  • Ähnlich wie bei proprietärer Middleware, die bereits von vielen Videospielen genutzt wird (Bink, SpeedTree, PhysX usw.), ist die Verteilung zusätzlicher .dll-Dateien nichts Ungewöhnliches.
  • Die meisten Game-Launcher (Steam, GOG, Epic usw.) verlangen ebenfalls ihre jeweiligen .DLLs.
  • Viele Spiele verwenden D3D11On12, und viele veröffentlichte Spiele enthalten dxil.dll in ihren Installationsdateien.
  • Die Arbeit, die Code-Signierung rückzuentwickeln und neu zu implementieren, ist erstaunlich, insbesondere weil die Ausgabe bitgenau mit der von dxil.dll identisch ist.
  • Wer jedoch einen einfacheren Weg bevorzugt, kann sich auch einfach dafür entscheiden, die DLL zu verteilen.

• Frage zur Signatur von DXIL.dll

  • Ist die von DXIL.dll ausgeführte Signatur einfach nur ein modifiziertes MD5?

• DXCs Änderungen an LLVMs Codegen-Schicht und Infrastruktur

  • Der LLVM-Fork von DXC entfernt oder beschädigt LLVMs Codegen-Schicht und Infrastruktur.
  • Dieses Problem zu beheben und die beschädigten LLVM-Funktionen wiederherzustellen, wäre eine gewaltige Aufgabe.
  • Aufgrund begrenzter Ressourcen gibt es derzeit keine Pläne, dieses Problem im neuen DXC-Compiler zu lösen.
  • Künftig könnte Clang möglicherweise die Erzeugung von DXBC unterstützen, doch diese Arbeit wird sich zuerst auf die Unterstützung der Erzeugung von DXIL und SPIR-V konzentrieren und daher vermutlich erst in einigen Jahren beginnen.
  • Es wird Dank dafür ausgedrückt, dass von Microsoft aus klare Erwartungen gesetzt werden.

• Rat zum Mach-Ökosystem

  • Es wird empfohlen, insbesondere mach-sysgpu zu untersuchen, eine vollständige Neuimplementierung von WebGPU, die hauptsächlich vom 17-jährigen Ali Chraghi geschrieben wurde.

• Diskussion über SDL_gpu und SDL3

  • Das SDL-Team entwickelt derzeit eine neue Shader-Sprache namens SDL_gpu, die mit SDL3 veröffentlicht werden soll.
  • Sie soll eine Möglichkeit bieten, plattformübergreifend an 3D-Grafik in Spielen zu arbeiten.

• Einsatz der Sprache Zig

  • Zig selbst als Shading-Sprache zu verwenden, wäre großartig.
  • Zig ist eine echte Sprache, ein Build-System und eine Shading-Sprache zugleich.

• Dank für Infrastrukturarbeit

  • Solche Infrastrukturarbeit zu lesen, ist erfreulich, weil sie viele Türen öffnet.

• Aussprache von DXIL

  • DXIL wird wie „dixel“ ausgesprochen, also wie „pixel“ mit einem „d“ statt einem „p“.