Développer un compilateur de shaders DirectX meilleur que celui de Microsoft

Concevoir un compilateur de shaders DirectX meilleur que celui de Microsoft

• Récit sur l’état complexe du compilateur de shaders DirectX de Microsoft et sur les efforts visant à offrir une meilleure expérience aux développeurs de jeux.
• Développement en cours, avec Zig, d’une API graphique expérimentale appelée sysgpu pour le moteur Mach, successeur de WebGPU, avec prise en charge prévue des backends Metal, Vulkan, Direct3D et OpenGL.
• Il faut compiler des programmes de shaders utilisables avec Direct3D 12.

Bref historique de DirectX

• L’API graphique DirectX utilise HLSL comme langage de shading.
• Avant Direct3D 11, un compilateur nommé FXC était utilisé, connu notamment pour sa lenteur et la génération d’un code peu optimisé.

FXC n’est plus utilisé, et DXC est arrivé avec Direct3D 12

• Avec la sortie de Direct3D 12 et de Shader Model 6.0 (SM6), Microsoft a abandonné FXC et présenté un nouveau compilateur appelé DXC.
• DXC est un fork officiel par Microsoft de LLVM/Clang v3.7, dont les modifications sont clairement signalées dans les commentaires.

Ce que les pilotes DirectX prennent au petit-déjeuner : DXBC ou DXIL

• HLSL est le langage de prédilection pour programmer avec Direct3D, mais dans la pratique, les GPU reposent sur des architectures de calcul et des exigences variées.
• Microsoft fournit une API frontend conviviale pour les développeurs, tandis que les fabricants de matériel indépendants écrivent des pilotes qui transforment cela vers quelque chose au plus proche de l’ISA réelle du matériel.
• Avec l’arrivée de DirectX 12 et de Shader Model 6.0, un nouveau format appelé DXIL est utilisé à la place de DXBC.

DXIL

• DXIL est le format officiel actuellement utilisé par les fabricants de pilotes DirectX 12.
• Les développeurs de jeux utilisent le compilateur DXC pour générer du bytecode DXIL, puis le transmettent au pilote graphique afin qu’il soit converti en véritable code machine exécuté sur le matériel GPU.

Modifications du fork LLVM de Microsoft

• Microsoft reconnaît qu’il n’est pas idéal que les fabricants de pilotes indépendants utilisent un format spécifique de bitcode LLVM, et admet que maintenir un fork de LLVM n’a rien d’agréable.
• Microsoft a commencé à travailler à l’intégration directe de la prise en charge de la compilation HLSL dans LLVM/Clang.

Défis pour les développeurs de jeux, WebGPU, etc.

• Une couche d’abstraction graphique doit fournir un langage de shading unifié, et aujourd’hui la plupart des implémentations de WebGPU compilent HLSL vers DXBC ou DXIL.

Détour simple : SPIR-V

• Vulkan/SPIR-V utilise une approche similaire, et c’est le fabricant du GPU qui décide si SPIR-V est optimisé ou non.

Faut-il utiliser dxcompiler.dll ou non ?

• Les runtimes WebGPU doivent choisir entre le nouveau compilateur HLSL DXC, ou l’ancien compilateur FXC officiellement abandonné, moins bon en performances et en qualité du code généré.

Pourquoi ne peut-on pas faire un lien statique ?

• Le fork LLVM de Microsoft ne prend pas en charge l’édition de liens statique, en raison de la complexité du système de build.

Présentation de dxil.dll — un blob propriétaire de signature de code pour les shaders DirectX

• dxil.dll n’est pas construit à partir des sources et dépend d’un blob de code propriétaire, spécifique à chaque plateforme, dans le dépôt « open source » de Microsoft.

Problèmes de prise en charge des plateformes

• Microsoft ne distribue dxil.dll que pour Windows (x86/arm) et Linux (x86), sans fournir de binaire pour macOS ni pour Linux aarch64.

Résumé

• Il est impossible de construire DXC comme bibliothèque statique, et restaurer les fonctionnalités LLVM à cause du blob propriétaire de signature de code représenterait un travail énorme.
• Il n’est pas possible d’effectuer une compilation hors ligne de shaders pour des jeux multiplateformes depuis des pipelines CI sur macOS ou Linux arm.

Amélioration du système de build

• Exploration d’un passage du système de build CMake vers build.zig afin de permettre une construction sous la forme d’une unique bibliothèque statique.

Résolution des dépendances aux bibliothèques dynamiques

• Fork de la base de code DXC et modification du code C++ pour supprimer les dépendances aux bibliothèques dynamiques.

Résolution de la signature de code propriétaire

• Une méthode a été trouvée pour compiler des shaders HLSL sans dépendre de dxil.dll.

Résultat

• Mise à disposition d’une bibliothèque dxcompiler et d’un CLI dxc sous forme de binaires statiques ne dépendant pas du dxil.dll propriétaire.
• Les binaires pour macOS, Linux et Windows sont construits dans le pipeline CI.

Points à noter

• Certains binaires ne sont pas encore construits ou testés, et il est prévu d’utiliser Zig lui-même comme langage de shading à la place de HLSL.

Note personnelle

• Après avoir obtenu un emploi technique à temps plein sous le nom de Stephen, l’auteur est actif en ligne pour construire le moteur Mach.
• Il est enraciné dans le FOSS et estime qu’il faut posséder ses outils et être rendu plus autonome par eux.
• Son rêve est de construire Mach pour tout le monde et de gagner sa vie en vendant des jeux de haute qualité.

Merci de votre lecture

• Consultez machengine.org.
• Envisagez de soutenir le développement pour permettre davantage de travail.
• Rejoignez le serveur Discord de Mach.
• Soutenez le projet sur GitHub.
• machengine.org

L’avis de GN⁺

• Le point le plus important de cet article est l’effort de la communauté de développeurs pour surmonter la complexité et les limites de DXC, le compilateur de shaders DirectX de Microsoft.
• En utilisant Zig pour améliorer le système de build de DXC et en proposant une nouvelle approche pour compiler des shaders HLSL sans dépendre du dxil.dll propriétaire, le développeur du moteur Mach apporte une contribution importante au développement de jeux multiplateforme.
• L’article souligne l’importance du logiciel open source et le fait que les développeurs doivent pouvoir posséder et contrôler leurs outils, tout en montrant la valeur de la collaboration et de l’innovation au sein de la communauté technique.

[GN⁺]

Avis Hacker News

• Un excellent aperçu de la complexité de la compilation de shaders pour les API 3D

  • Un aperçu est proposé sur les problèmes complexes de la compilation croisée de shaders entre différentes API 3D.
  • Même si l’accent est mis sur D3D et Microsoft, la situation n’est pas vraiment meilleure avec les autres API 3D.
  • Par exemple, il est impossible de cross-compiler des shaders Metal depuis un hôte Linux, et cela n’est possible que sur macOS et, plus récemment, sur Windows.
  • Si l’équipe Mach parvient à faire de « Zig comme compilateur de shaders cross-3D-API » une réussite, et à le rendre aussi fluide que « Zig comme toolchain de cross-compilation », ce serait l’événement le plus important en infographie depuis 1995.

• Problèmes liés à Godot

  • La prise en charge de Direct3D 12 dépend actuellement de la bibliothèque propriétaire dxil.dll du DirectX Shader Compiler distribuée avec Godot.
  • Distribuer un logiciel propriétaire va à l’encontre de la mission du projet Godot.

• Discussion sur la distribution de .dll supplémentaires

  • Il n’est pas inhabituel de distribuer des .dll supplémentaires, au même titre que des middlewares propriétaires déjà utilisés par de nombreux jeux vidéo (Bink, SpeedTree, PhysX, etc.).
  • La plupart des lanceurs de jeux (Steam, GOG, Epic, etc.) exigent eux aussi diverses .DLL.
  • De nombreux jeux utilisent D3D11On12, et beaucoup de jeux déjà sortis incluent dxil.dll dans leurs fichiers d’installation.
  • Le travail de rétro-ingénierie et de réimplémentation de la signature de code est particulièrement impressionnant, d’autant plus que la sortie est identique bit à bit à celle de dxil.dll.
  • Cela dit, ceux qui préfèrent une solution plus simple peuvent tout simplement choisir de distribuer la DLL.

• Question sur la signature de DXIL.dll

  • La signature effectuée par DXIL.dll est-elle simplement un MD5 modifié ?

• Changements de DXC dans la couche de génération de code et l’infrastructure de LLVM

  • Le fork LLVM de DXC supprime ou endommage la couche de génération de code et l’infrastructure de LLVM.
  • Corriger ce problème et restaurer les fonctionnalités cassées de LLVM représenterait un travail énorme.
  • En raison de contraintes de ressources, il n’est pas prévu de résoudre ce problème dans le nouveau compilateur DXC.
  • Il sera peut-être possible à l’avenir de prendre en charge la génération de DXBC dans Clang, mais ce travail ne commencera probablement pas avant plusieurs années, car la priorité est d’abord de prendre en charge la génération de DXIL et de SPIR-V.
  • Remerciements à Microsoft pour avoir défini des attentes claires.

• Conseil sur l’écosystème Mach

  • Il est recommandé d’examiner en particulier mach-sysgpu, une réimplémentation complète de WebGPU, principalement écrite par Ali Chraghi, âgé de 17 ans.

• Discussion sur SDL_gpu et SDL3

  • L’équipe SDL développe un nouveau langage de shaders appelé SDL_gpu, qui sera lancé avec SDL3.
  • Cela offrira un moyen de travailler de façon multiplateforme sur les graphismes 3D dans les jeux.

• Utilisation du langage Zig

  • Utiliser Zig lui-même comme langage de shading serait formidable.
  • Zig est un véritable langage, qui fait aussi office de système de build et de langage de shading.

• Expression de gratitude pour ce travail d’infrastructure

  • C’est un plaisir à lire, car ce type de travail d’infrastructure ouvre énormément de portes.

• Remarque sur la prononciation de DXIL

  • DXIL se prononce « dixel », comme « pixel » en remplaçant le « p » par un « d ».