Skip to main content

Compilation des objets d’état de pipeline

D3D12 fournit l’interface d’objet d’état de pipeline (PSO) pour configurer le GPU avec les nuanceurs et l’état de rendu. Le flux de travail multiplateforme standard pour créer des PSO consiste à précompiler les nuanceurs à l’aide de DXC lors d’un processus de génération, puis à remplir un descripteur d’état de pipeline graphique ou de calcul (p. ex. D3D12_GRAPHICS_PIPELINE_STATE_DESC) avec le bytecode des nuanceurs et l’état à l’exécution. La validation du pilote garantit la cohérence des entrées/sorties et de l’état pour chaque étape successive du pipeline. Sur PC, la compilation des PSO à l’exécution est nécessaire puisque le GPU de l’utilisateur final est généralement inconnu au moment de la génération. Le processus DXC hors ligne doit donc compiler vers un format de bytecode intermédiaire, la représentation intermédiaire basée sur LLVM, DXIL (DirectX Intermediate Language). La création du PSO à l’exécution avec l’une des API disponibles (ci-dessous) amène le pilote du GPU à finaliser le code du nuanceur en compilant le bytecode DXIL en instructions GPU, qui peuvent ensuite être exécutées sur le GPU. À l’exécution :
API pertinentes :

Objets d’état de pipeline sérialisés

La plateforme XBOX fige la configuration matérielle, ce qui rend inutile la distribution d’une représentation intermédiaire du code des nuanceurs. Cela permet de déplacer le processus de compilation des PSO vers une étape de génération, éliminant ainsi la surcharge consacrée à la création des PSO au démarrage du titre. Des extensions d’API XBOX ont été ajoutées pour sérialiser les PSO dans un format de blob binaire qui peut être enregistré directement sur le disque. À l’exécution, ces blobs peuvent être chargés à partir du disque et désérialisés en un état de pipeline fonctionnel. Les PSO peuvent toujours être créés à l’exécution à l’aide des fonctionnalités D3D12 standard, mais la sérialisation offre une façon d’optimiser la vitesse de démarrage. Puisque les PSO sérialisés sont distribués dans les builds de package, l’un des piliers de conception consiste à réduire au minimum leur empreinte mémoire. Les blobs produits par SerializeGraphicsPipelineStateX doivent être dédupliqués parmi tous les PSO précompilés afin de réduire les besoins en mémoire. Les autres métadonnées non pertinentes pour l’exécution sont supprimées lors de la sérialisation, ce qui empêche de resérialiser des PSO déjà désérialisés; une telle tentative échoue avec un message de validation. Les API de sérialisation (ci-dessous) ne sont pas disponibles dans les builds commerciales. Notez que le processus utilisé pour précompiler les PSO doit utiliser un ID3D12Device créé à partir d’une bibliothèque ciblant la plateforme. La fonction D3D12CreateDevice se trouve dans le dossier toolkit de l’installation du GDK, dans d3d12_x.h pour la XBOX One ou d3d12_xs.h pour la XBOX Series X|S; effectuez la liaison avec d3d12_x.lib ou d3d12_xs.lib en conséquence. Ces bibliothèques exigent que les DLL du GDK soient accessibles à partir du répertoire de travail ou au moyen de la variable système PATH. Les DLL se trouvent dans le dossier bin de la version correspondante du GDK, p. ex. C:\\Program Files (x86)\\Microsoft GDK\\200804\\GXDK\\bin pour la QFE 4 d’août 2020. Au moment de la génération :
À l’exécution :
Voici une brève description du contenu de chaque élément de données sérialisées : D3D12XBOX_SERIALIZE_GRAPHICS_PIPELINE_STATE::pPacket
  • Informations d’exécution du processeur de commandes
  • État du GPU pour les états de fusion/rastérisation/profondeur-gabarit
  • État du GPU pour les paramètres RTV/DSV
  • État du GPU pour le traitement des sommets/index, la tessellation et la sortie de flux
  • État du GPU pour chaque étape matérielle
D3D12XBOX_SERIALIZE_GRAPHICS_PIPELINE_STATE::pMetadata
  • Hachage CRC32 du PSO sérialisé
  • Numéro de version de la structure sérialisée
  • Données de validation
  • Forme compacte des arguments de création du PSO
  • Configurations de la disposition d’entrée et de la sortie de flux
D3D12XBOX_SERIALIZE_SHADER::pGpuInstructions
  • Instructions GPU précompilées du nuanceur matériel
D3D12XBOX_SERIALIZE_SHADER::pMetaData
  • Numéro de version de la structure sérialisée
  • Métadonnées du compilateur de nuanceurs
  • Informations sur les nuanceurs pour PIX
API pertinentes :

Objets d’état de pipeline dérivés

Une autre fonctionnalité exposée par l’API D3D12.X est celle des objets d’état de pipeline « dérivés ». Cette fonctionnalité crée des variantes légères de PSO existants, qui ne diffèrent que par l’état matériel (état de profondeur-gabarit, état du rastériseur, état de fusion, masque d’échantillonnage et limites des nuanceurs). La dérivation d’un PSO entraîne une surcharge à l’exécution négligeable par rapport à la compilation d’un PSO. Cela permet au développeur de créer un seul PSO, lié à un ensemble commun de nuanceurs, puis d’en tirer un nombre arbitraire de variantes en ne payant le coût complet à l’exécution que pour la création initiale du PSO.
API pertinentes :

Objets d’état de pipeline sérialisés et dérivés

Utilisés conjointement, les PSO sérialisés et dérivés offrent un avantage supplémentaire pour réduire la taille du package. Les PSO dérivés permettent aux titres de réduire le nombre de PSO sérialisés à un sous-ensemble de l’ensemble total utilisé par le titre. En dédupliquant les PSO selon les propriétés qui ne peuvent pas être remplacées par les PSO dérivés, on obtient un ensemble « de base » à partir duquel tous les autres PSO du titre peuvent être dérivés. Le cas d’utilisation type de ces deux fonctionnalités serait le suivant :
  • Identifier les PSO ayant des combinaisons uniques de signature racine, de disposition d’entrée, d’étapes de nuanceurs, de sorties de flux et de cibles de rendu.
  • Sérialiser cet ensemble dédupliqué de PSO de base dans un processus hors ligne et le distribuer dans le package.
  • Charger les PSO de base à partir du fichier au démarrage et dériver toutes les variantes de PSO nécessaires au titre.

Contraintes liées aux objets d’état de pipeline dérivés

Une restriction notable des PSO dérivés est qu’ils ne peuvent pas modifier le code compilé des nuanceurs. C’est pourquoi les dispositions d’entrée, les formats des cibles de rendu et les paramètres de sortie de flux ne sont pas des options de D3D12XBOX_DERIVED_GRAPHICS_STATE_DESC, puisqu’ils nécessitent de modifier les instructions GPU du PSO compilé. Le pilote choisit le ou les types de données d’exportation des nuanceurs appropriés lors de la compilation du PSO; les types d’exportation de nuanceurs pris en charge sont uint, sint, unorm, snorm ou float de 16 ou 32 bits. Le pilote sélectionne le plus petit type dont la précision est supérieure ou égale à celle de la cible de rendu, tout en respectant la configuration du matériel de fusion. Pour mettre en œuvre son choix, le pilote modifie le code compilé du nuanceur avec les instructions d’exportation appropriées, qui convertissent le type utilisé pour les opérations du nuanceur vers le type d’exportation sélectionné par le pilote. Une fois cette modification effectuée, le pilote ne modifie plus ces instructions GPU finalisées. Le choix final des instructions d’exportation des nuanceurs est déterminé par quelques facteurs clés :
  • Les types et le nombre de cibles dans lesquelles le code HLSL écrit (SV_TargetN)
  • Les formats et le nombre de cibles de rendu du PSO
  • Le paramètre alpha-to-coverage
  • Les paramètres de l’état de fusion
Dans le cas d’un rendu opaque (fusion désactivée), le ou les types de sortie peuvent être n’importe lequel des types d’exportation de nuanceurs pris en charge : uint, sint, unorm, snorm ou float de 16 ou 32 bits. La valeur est exportée par le nuanceur, convertie dans le type de la cible de rendu par le Color Block (CB), puis écrite en mémoire. Lorsque la fusion est activée, le pilote est contraint de limiter les types d’exportation des nuanceurs à float de 16 ou 32 bits, puisque ce sont les seuls types pris en charge que le CB accepte en entrée de l’opération de fusion. La valeur fusionnée est ensuite convertie dans le type de la cible de rendu et écrite en mémoire. Ces détails entraînent des contraintes subtiles sur les remplacements d’état de fusion applicables aux PSO dérivés. L’état de fusion remplacé peut rendre les exigences d’exportation du PSO dérivé incompatibles avec le choix d’instruction d’exportation déterminé lors de la compilation du PSO de base, qui a été intégré aux instructions GPU. Si une exportation calculée diffère entre le PSO de base et le PSO dérivé, une erreur de validation est générée. Quelques exemples qui provoquent des types d’exportation incompatibles et qui échoueraient à la validation : Exemple 1 -
Exemple 2 -
Exemple 3 -

Les PSO sérialisés vous conviennent-ils?

Bien que les PSO sérialisés aient été créés pour réduire la taille des packages et les coûts à l’exécution liés au contenu de nuanceurs des jeux, la création et la maintenance d’une telle étape de génération entraînent certainement un coût de développement non négligeable. Les développeurs constatent souvent que la distribution de nuanceurs précompilés avec un DXIL épuré offre des performances suffisantes pour leurs besoins, ce qui est souvent déjà pris en charge par les pipelines de contenu existants. Le back-end du pilote XBOX a été optimisé avec plusieurs mécanismes de mise en cache afin de réduire les besoins en mémoire à l’exécution et le temps de compilation des PSO, pour faciliter cette approche. Selon le contenu de nuanceurs d’un titre, les développeurs peuvent trouver qu’une méthode est préférable pour la taille du package, la mémoire à l’exécution ou le temps de compilation des PSO. Éviter la maintenance d’un pipeline de contenu de sérialisation des PSO est un autre point à considérer. Tester les deux options avec le contenu de votre titre vous donnera une idée plus claire du meilleur choix pour votre titre.
Last modified on October 6, 2026