Compilateur de nuanceurs - XBOX Game Development Documentation

Le DirectX Shader Compiler (DXCompiler ou DXC) est un nouveau compilateur de nuanceurs pour Windows et XBOX. DXC est déjà requis pour le lancer de rayons et d’autres nouvelles fonctionnalités sur Windows. À l’avenir, DXC sera la voie prise en charge pour activer de nombreuses autres fonctionnalités, y compris des fonctionnalités disponibles sur les futures plateformes de jeu en cours de développement. Nous ajouterons de nombreux autres intrinsèques XBOX, la prise en charge de nouveaux modèles de nuanceur ainsi que de nombreuses autres fonctionnalités et améliorations des performances dans les prochaines versions. L’ancien D3D Shader Compiler (D3DCompiler ou FXC) est déprécié et n’est plus pris en charge.

HLSL 2021

Depuis le GDK d’octobre 2023, DXC utilise par défaut le langage HLSL 2021. HLSL 2021 ajoute la prise en charge de diverses fonctionnalités de style C++ :

Fonctions et structures modèles
Champs de bits sur les éléments de structure
Surcharge d’opérateurs
Surcharge de fonctions de style C++
Court-circuit des opérations logiques pour les scalaires

Pour plus de renseignements, consultez HLSL 2021 et le guide de migration vers HLSL 2021. Pour utiliser le langage par défaut précédent, HLSL 2018, passez -HV 2018 au compilateur. La liste des problèmes en cours sur GitHub est disponible sous l’étiquette HLSL 2021. N’hésitez pas à signaler un bogue sur GitHub ou à nous écrire à l’adresse AskHLSL@microsoft.com pour nous faire part de vos commentaires et problèmes.

En cours de développement

DXC pour XBOX est actuellement en cours de développement actif. Nous ajouterons une nouvelle interface .dll simplifiée pour le compilateur, de nombreux autres intrinsèques XBOX, la prise en charge de nouveaux modèles de nuanceur ainsi que de nombreuses autres fonctionnalités et améliorations des performances dans les prochaines versions. Vous pouvez communiquer avec l’équipe à l’adresse AskHLSL@microsoft.com.

Aide sur le compilateur de nuanceurs

Utilisation de DXC : comment utiliser l’interface en ligne de commande (dxc) et l’interface .dll (dxcompiler_x.dll) du compilateur
Guide de portage de FXC vers DXC : quelques conseils et astuces pour le portage des nuanceurs vers DXC

Fonctionnalités propres à XBOX

DXC pour XBOX prend en charge de nombreux intrinsèques et définitions spéciales qui ne sont pas disponibles sur Windows. Pour plus de renseignements, consultez les rubriques suivantes :

Précompilation

Sur XBOX, le compilateur DXC peut compiler le HLSL jusqu’aux instructions finales de l’architecture du jeu d’instructions (ISA) des GPU XBOX. Les titres peuvent ainsi éviter une étape coûteuse de compilation à l’exécution, du DXIL vers les instructions ISA. Nous appelons cette étape de compilation complète « précompilation », car elle compile les nuanceurs en ISA hors ligne (sur le PC de développement) plutôt qu’en ligne (sur la console XBOX). Diverses définitions permettent de contrôler la précompilation. Sur XBOX, il existe essentiellement 3 façons de compiler les nuanceurs. A. Précompilation hors ligne avec DXIL supprimé (/D__XBOX_STRIP_DXIL=1)

+--------------+
| DXC (offline)|
+--------------+

HLSL -> DXIL  -> ISA
  |           |
  |           +
  +------> RootSig

+---------------+
| XBOX (runtime)|
+---------------+

ISA  -> Use ISA if valid, otherwise error
     ^
     |
     +
  RootSig

B. Précompilation hors ligne avec DXIL conservé (/D__XBOX_STRIP_DXIL=0)

+--------------+
| DXC (offline)|
+--------------+

HLSL ->  DXIL -> DXIL+ISA
  |           |
  |           +
  +------> RootSig

+---------------+
| XBOX (runtime)|
+---------------+

DXIL+ISA -> Use ISA if valid, otherwise recompile from DXIL
         |
         +
       RootSig

C. Hors ligne sans précompilation (/D__XBOX_DISABLE_PRECOMPILE)

+--------------+
| DXC (offline)|
+--------------+

HLSL -> DXIL

+---------------+
| XBOX (runtime)|
+---------------+

DXIL  -> compile to ISA
      |
      +
    RootSig

Sur PC, seule l’option C est disponible, mais sur XBOX, nous privilégions l’option A, car elle n’entraîne aucune surcharge à l’exécution. Les compilateurs de nuanceurs pour PC sont optimisés pour fonctionner en mode juste-à-temps (JIT) afin de compiler rapidement DXIL -> ISA. Sur XBOX, nous disposons d’un compilateur plus lourd, car nous prévoyons qu’il s’exécute hors ligne la plupart du temps et qu’il peut prendre plus de temps pour optimiser le code.

Documentation externe

Vous pouvez consulter l’intégralité du code source, et même contribuer au nouveau compilateur frontal, sur GitHub : DirectXShaderCompiler. La documentation générale sur le langage HLSL (High-Level Shader Language) est disponible sur Microsoft Docs : Reference for HLSL. La documentation sur le nouveau compilateur et les modèles de nuanceur plus avancés se trouve maintenant sur GitHub : wiki DirectXShaderCompiler.

Différences entre DXC sur XBOX et DXC sur Windows

Sur Windows, les nuanceurs sont compilés en DXIL, qui est ensuite envoyé au pilote GPU pour la compilation finale. Sur XBOX, comme le matériel GPU cible est fixe, les nuanceurs sont précompilés par défaut, ce qui permet d’ignorer la phase de compilation à l’exécution.

Pour compiler un nuanceur sur XBOX, une signature racine doit être spécifiée afin que le compilateur puisse précompiler le nuanceur. Si le nuanceur est utilisé à l’exécution avec une autre signature racine, une compilation à l’exécution se produit, ce qui est souvent indésirable. Notez que pour tester des nuanceurs ou pour les outils, vous pouvez ignorer complètement la précompilation à l’aide de la définition __XBOX_DISABLE_PRECOMPILE, mais cela n’est pas recommandé pour une utilisation normale à l’exécution.

Prise en charge des fonctionnalités des modèles de nuanceur sur XBOX

XBOX offre une prise en charge partielle des fonctionnalités facultatives des modèles de nuanceur à partir du modèle de nuanceur 6.0. Si aucune fonctionnalité facultative non prise en charge n’est utilisée, vous pouvez compiler vos nuanceurs pour cibler n’importe quel modèle de nuanceur sur XBOX. Les détails des fonctionnalités des modèles de nuanceur sont disponibles sur GitHub. Le tableau ci-dessous détaille la prise en charge des fonctionnalités des modèles de nuanceur sur XBOX.

Modèle de nuanceur	Fonctionnalité	Famille XBOX One	Consoles XBOX Series
6.0	Wave Intrinsics	Partielle [1]	Oui
6.0	64-Bit Integers	Oui	Oui

6.1	SV_ViewID	Non	Non
6.1	SV_Barycentrics	Personnalisée [2]	Oui

6.2	16-Bit Scalar Types	Non	Oui
6.2	Denorm Mode	Non	Non

6.3	DirectX12 Raytracing (DXR)	Non	Oui

6.4	Packed Dot Product Intrinsics	Non	Oui
6.4	Variable Rate Shading	Non	Oui
6.4	Library Sub-objects	Non	Oui

6.5	DXR 1.1	Non	Non [3]
6.5	Sampler Feedback	Non	Oui
6.5	Mesh Shader	Non	Oui
6.5	Amplification Shader	Non	Oui
6.5	WaveMatch Intrinsics	Non	Non
6.5	WaveMultiPrefix Intrinsics	Non	Non

6.6	New Atomic Operations	Oui	Oui
6.6	Dynamic Resources	Oui	Oui
6.6	IsHelperLane Intrinsic	Oui	Oui
6.6	Derivative Operations in CS, MS, AS	Non	Non
6.6	Pack and Unpack Intrinsics	Non	Non
6.6	WaveSize	Non	Non
6.6	Raytracing Payload Access Qualifiers	Non	Non [4]

6.7	GatherRaw	Non	Non
6.7	SampleCmpLevel	Non	Non
6.7	Programmable Texture Offsets	Non	Non [5]
6.7	Writable MSAA Textures	Non	Non [6]
6.7	QuadAny/QuadAll	Non	Non
6.7	WaveOpsIncludeHelperLanes	Non	Non [7]

[1] Consultez les intrinsèques de vague XBOX pour obtenir la liste des intrinsèques et types pris en charge. [2] Pour la famille XBOX One, nous ne pouvons pas faire pivoter les sommets pour y accéder dans l’ordre du sommet provoquant imposé par la spécification; ils sont donc retournés dans l’ordre fourni par le matériel. Cela correspond au comportement des intrinsèques barycentriques XBOX existants. [3] Nous ne prenons pas en charge les objets RayQuery de DXR 1.1. Nous prenons toutefois en charge une technique propre à XBOX, appelée parcours inline, qui peut être utilisée à la place des objets RayQuery. [4] Les qualificateurs d’accès à la charge utile sont ignorés sur XBOX. Sur XBOX Series X|S, le compilateur de nuanceurs prend en charge les types 16 bits natifs, qui peuvent être activés à l’aide de l’indicateur de compilation -enable-16bit-types et en définissant la version du modèle de nuanceur sur 6.2 ou supérieure. Sur XBOX Series X|S, il est fortement recommandé d’utiliser des types 16 bits natifs plutôt que des types à précision minimale autant que possible. Dans une prochaine version, l’utilisation de -enable-16bit-types ne sera plus nécessaire, car les types 16 bits natifs seront activés par défaut. [5] Les décalages programmables génèrent de l’ISA si l’on tente de les utiliser, mais le code généré est incorrect et ne fonctionnera pas comme prévu. [6] Cette fonctionnalité est disponible par l’intrinsèque HLSL XB_Store [7] L’attribut [WaveOpsIncludeHelperLanes] se compile, mais le compilateur XBOX l’ignore actuellement.

Problèmes connus

Si vous utilisez des allocateurs personnalisés (DxcCreateInstance2), ils ne doivent pas être libérés avant le déchargement de la .dll dxcompiler.
PIX ne peut pas trouver automatiquement les .pdb si le nuanceur est sérialisé et que le nom du .pdb ne correspond pas à la chaîne de hachage. À l’avenir, nous ajouterons à PIX une option permettant de rechercher dans tous les .pdb de votre chemin de recherche de .pdb PIX un hachage correspondant, quel que soit le nom du .pdb.
La taille du DXIL est en moyenne supérieure à celle du DXBC. Nous travaillons activement sur les problèmes de taille du DXIL.
La taille des données de réflexion sera considérablement réduite dans une prochaine version.
Le débogueur HLSL de PIX pour les nuanceurs créés avec DXC présente de nombreux problèmes. Nous travaillons activement à en améliorer la qualité.
__XBOX_ENABLE_SIGNATURE_PACKING ne s’applique actuellement qu’aux étapes de nuanceur de sommets et de nuanceur de pixels.
Nous travaillons activement à améliorer les performances de compilation et d’exécution. Si certains de vos nuanceurs sont trop longs à compiler ou n’atteignent pas les performances d’exécution attendues, écrivez-nous à l’adresse AskHLSL@microsoft.com ou contactez-nous sur les forums XBOX.

Comprendre les phases et la terminologie des compilateurs GPU

Les compilateurs GPU se composent d’un « frontal », qui analyse le HLSL pour le convertir en un langage intermédiaire, lequel est consommé par le compilateur « dorsal » qui effectue des optimisations de bas niveau propres à la machine et produit le code machine du GPU.

Front end -> Intermediate Language -> Back end

Notre ancien compilateur frontal (appelé D3DCompiler ou FXC) et notre ancien langage intermédiaire (DXBC) ont tous deux été remplacés par un nouveau compilateur frontal (DXCompiler ou DXC) et un nouveau langage intermédiaire (DXIL), basés sur les standards ouverts Clang et LLVM. De plus, sur XBOX, Microsoft est passé de la base de code dorsale « SC » à une base de code mise à jour appelée « NB », aussi basée sur LLVM. La complexité du code GPU ayant augmenté, nous devions passer à une technologie plus avancée et plus flexible. Nouveau flux de compilation :

DXC -> DXIL -> NB

Implémentation de NGG dans le compilateur XBOX (Scarlett uniquement)

NGG (Next Generation Geometry) ignore l’étape matérielle IA et permet un débit de primitives beaucoup plus élevé. Indicateurs supplémentaires qui contrôlent la génération de code NGG :

Indicateur	Description
__XBOX_PRECOMPILE_NGG	Cet indicateur active la précompilation d’un nuanceur NGG pour les étapes de sortie activées. Actuellement, VS est la seule étape prise en charge pour le NGG automatique. Notez que les nuanceurs de maillage ciblent directement NGG. Vous devez aussi utiliser D3D12XBOX_PIPELINE_STATE_FLAG_VS_NGG sur CreatePSO pour activer les nuanceurs NGG dans le pilote.
__XBOX_NGG_PASSTHROUGH	L’activation de l’indicateur __XBOX_PRECOMPILE_NGG insère automatiquement du code d’élimination. L’élimination automatique peut être explicitement désactivée, tout en conservant la fonctionnalité NGG, en activant la génération de nuanceurs « passthrough ». Cette option peut avoir un intérêt limité pour les charges de travail riches en sommets dont on sait qu’elles éliminent peu (ou qui manquent trop d’occasions d’élimination basée sur les nuanceurs).

Pour tirer parti de l’élimination automatique, le titre doit :

Exporter une valeur SV_Position depuis le VS avec ses quatre composantes écrites.
Définir D3D12_RASTERIZER_DESC.CullMode dans D3D12_GRAPHICS_PIPELINE_STATE_DESC sur une valeur autre que D3D12_CULL_MODE_NONE.

La valeur de D3D12_RASTERIZER_DESC.FrontCounterClockwise est lue à l’exécution pour déterminer l’ordre d’enroulement des sommets. Actuellement, les types d’élimination suivants sont effectués :

Élimination des faces arrière
Élimination des triangles d’aire nulle
Élimination selon le tronc de visualisation

Voici l’implémentation HLSL de la fonction d’élimination automatique.

    bool CullTriangle(
        float4 posH_0, float4 posH_1, float4 posH_2,
        bool cullBackFace, bool backFaceOrderCW )
    {
        // Test that all points are in front of the camera. W is usually a linear distance in the forward axis. Negative W
        // values are problematic because they invert all the following tests. It's better to cull now and assume positive values.
        float maxW = max(max(posH_0.w, posH_1.w), posH_2.w);
        bool negativeWCull = maxW <= 0.0f;
        if (negativeWCull)
            return true;
        
        // If some of the W values are negative, the triangle straddles the W=0 plane creating an inversion. Let the triangle
        // clipper sort it out. It's not worth the ALU.
        float minW = min(min(posH_0.w, posH_1.w), posH_2.w);
        bool nearPlaneClip = minW <= 0.0f;
        if (nearPlaneClip)
            return false;
    
        // To be correct, we need to fix the order of the vertices provided, know which direction should be culled (or not)
        // and adjust the sign of the test appropriately. A zero determinant should always cull because it has zero-area.
        float discriminant = determinant(float3x3(posH_0.xyw, posH_1.xyw, posH_2.xyw));
        discriminant = backFaceOrderCW ? +discriminant : -discriminant;
        bool isBackFaceOrZeroArea = discriminant <= 0.0f;
        if (cullBackFace && isBackFaceOrZeroArea)
            return true;
        
        bool cullLeft   = (posH_0.x < -posH_0.w) && (posH_1.x < -posH_1.w) && (posH_2.x < -posH_2.w);
        bool cullRight  = (posH_0.x > +posH_0.w) && (posH_1.x > +posH_1.w) && (posH_2.x > +posH_2.w);
        bool cullBottom = (posH_0.y < -posH_0.w) && (posH_1.y < -posH_1.w) && (posH_2.y < -posH_2.w);
        bool cullTop    = (posH_0.y > +posH_0.w) && (posH_1.y > +posH_1.w) && (posH_2.y > +posH_2.w);
        
        if (cullLeft || cullRight || cullBottom || cullTop)
            return true;
    
        return false;
    }

Rentabilité de l’activation de NGG

Bien que l’objectif final soit d’activer l’élimination NGG par défaut, elle n’est actuellement rentable que dans quelques situations connues. Les voici :

Le matériel est limité par le traitement des primitives (4 primitives/cycle d’horloge)
Nombre élevé de sommets/primitives pour le dessin avec un maillage en serpentin (pour créer de longues séquences de sommets orientés vers l’arrière), de sorte que de longues séquences de sommets sont éliminées.
Nombreux accès mémoire qui ne servent qu’aux attributs
Grand nombre d’exportations d’attributs

Tout cela repose sur l’hypothèse qu’il existe un nombre suffisamment élevé de primitives éliminées pour justifier ne serait-ce qu’un des scénarios ci-dessus. Les dessins en plein écran, la géométrie du monde et l’élimination déjà présente dans le moteur réduisent l’intérêt de cette fonctionnalité. Si la charge de travail est déjà limitée par le débit de pixels, l’élimination NGG n’apportera pas non plus d’avantage.

Améliorations futures

Il s’agit d’une version initiale qui sera améliorée au fil du temps. Les améliorations prévues sont les suivantes :

Ajuster la taille des groupes de threads. L’élimination NGG nécessite l’allocation de LDS. Une taille de groupe de threads importante limite l’occupation du nuanceur compilé en raison des limites d’allocation de LDS.
Activer la sortie anticipée lorsque l’ensemble du groupe de threads est éliminé.
Exportations par primitive pour les attributs non interpolés.
Ajouter des heuristiques pour désactiver l’élimination lorsqu’il peut être déterminé statiquement qu’elle n’est pas rentable. Exemples :
1. Instructions dupliquées dans les sections de nuanceur avant et après l’élimination (en raison du partage entre les exportations de position et d’attributs).
2. Position.Z vaut 0 : triangle plat (2D) qui ne sera probablement pas éliminé.
3. Contournement des petits sous-groupes.
4. Autres optimisations mineures.

Nous envisageons aussi d’ajouter la prise en charge de fonctions d’élimination définies par l’utilisateur, que le compilateur pourrait appeler lors de la compilation pour NGG. Essayez cette fonctionnalité et faites-nous part de vos commentaires.

Voir aussi

Développement de jeux sur console XBOX (environnement et outils)

​HLSL 2021

​En cours de développement

​Aide sur le compilateur de nuanceurs

​Fonctionnalités propres à XBOX

​Précompilation

​Documentation externe

​Différences entre DXC sur XBOX et DXC sur Windows

​Prise en charge des fonctionnalités des modèles de nuanceur sur XBOX

​Problèmes connus

​Comprendre les phases et la terminologie des compilateurs GPU

​Implémentation de NGG dans le compilateur XBOX (Scarlett uniquement)

​Rentabilité de l’activation de NGG

​Améliorations futures

​Voir aussi