Skip to main content
Direct3D 12 sur le Game OS du Microsoft GDK (Direct3D 12.x) présente des différences notables par rapport à Direct3D 12 sur PC Windows (Direct3D 12/PC).

Différences générales

  • Le Game OS du Microsoft GDK prend en charge la sérialisation/désérialisation des objets d’état de pipeline (PSO) afin d’éviter les coûts de construction des PSO au moment de l’exécution dans le pilote. Cette fonctionnalité est identique à celle de l’ERA. Le Game OS du Microsoft GDK accepte comme entrées valides les shaders précompilés, les shaders non précompilés, les shaders dérivés et les PSO sérialisés. Nous recommandons d’utiliser des PSO sérialisés pour la rapidité, le gain d’espace et un meilleur contrôle par l’utilisateur.
  • XBOX fournit de l’ESRAM, ce qui permet d’utiliser les ressources de tampons et de textures dans la mémoire la plus rapide possible. Maximiser l’utilisation de l’ESRAM est essentiel pour obtenir des performances élevées. Dans Gestion native des ressources pour XBOX One, consultez la sous-section « Specifying Fast ESRAM Memory for a Buffer or Texture », et consultez Vue d’ensemble de la mémoire XG.
  • Les files d’attente de commandes du Game OS du Microsoft GDK ne sont pas thread-safe. Il incombe au titre de synchroniser explicitement l’accès multithread aux files d’attente de commandes graphiques, de calcul et de copie/DMA. À défaut, les commandes émises dans la file d’attente risquent d’être corrompues, ce qui peut entraîner des blocages ou des plantages du GPU.
  • Une seule file d’attente de commandes de chaque type peut être créée sur XBOX, sauf si l’extension CreateCommandQueueX est utilisée pour sélectionner explicitement un pipe/moteur et (pour le calcul) un index de file d’attente pour la file d’attente de commandes. Une seule file d’attente de commandes graphiques peut être créée, quelle que soit l’API utilisée. Une file d’attente de calcul ou de copie/DMA peut être créée par pipe/moteur GPU et index de file d’attente disponibles.
  • Les barrières de ressources du Game OS du Microsoft GDK encouragent une utilisation généralisée des transitions D3D12_RESOURCE_BARRIER_FLAG_BEGIN_ONLY et D3D12_RESOURCE_BARRIER_FLAG_END_ONLY, et il est recommandé de spécifier des indicateurs D3D12XBOX_RESOURCE_FLAG_PREFER* supplémentaires lors de la création de certains types de ressources (voir D3D12_RESOURCE_FLAGS). Consultez la section « Barrières de ressources » ci-dessous, ainsi que D3D12_RESOURCE_BARRIER_FLAGS.
  • Le Game OS du Microsoft GDK prend en charge un modèle de présentation différent du système de Present de chaîne d’échange de Direct3D 12 sur PC. Pour en savoir plus sur le nouveau modèle de présentation, consultez Planification et présentation des images sur XBOX One.
  • Le Game OS du Microsoft GDK encourage l’accès aux cibles de rendu multi-échantillonnées dans un état compressé pour des raisons de performances, et encourage également les ressources de profondeur/stencil compressées. Dans la section Barrières de ressources ci-dessous, consultez Utilisation directe des ressources compressées.
  • Le Game OS du Microsoft GDK prend en charge un certain nombre d’extensions matérielles propres au GPU.
  • Les extensions Direct3D 12.x du Game OS du Microsoft GDK fournissent les éléments suivants :
    • Types de tas de descripteurs supplémentaires
    • Manipulation directe des descripteurs
    • Composition de signatures racines et variantes de diffusion
    • Exécution asynchrone des listes de commandes (exécution avant fermeture)
  • Il incombe au titre de s’assurer que le GPU a terminé tous ses accès à une ressource avant de la détruire. Un titre doit insérer des fences à la fin des accès aux ressources et attendre que ces fences soient franchies avant de ramener à 0 le nombre de références des objets ressources.
  • Le Game OS du Microsoft GDK ne prend pas en charge l’utilisation du type de liste de commandes COPY (D3D12_COMMAND_LIST_TYPE_COPY) avec l’interface standard ID3D12GraphicsCommandList. Le Game OS du Microsoft GDK fournit plutôt une interface dédiée à la copie (ID3D12XboxDmaCommandList). Cette interface inclut la fonctionnalité de copie standard de ID3D12GraphicsCommandList ainsi que des extensions pour le matériel du moteur DMA XBOX, telles que la compression/décompression LZ et le décodage JPEG. Si vous prévoyez d’écrire du code multiplateforme pour les listes de commandes de copie Direct3D 12, nous vous recommandons d’utiliser un typedef pour l’interface de liste de commandes de copie, défini comme ID3D12XboxDmaCommandList sur le Game OS du Microsoft GDK et comme ID3D12GraphicsCommandList sur PC.

Pilotes retail, instrumenté et de débogage

Avec le Gaming eXtensions Development Kit (GXDK), trois pilotes peuvent être utilisés pour faciliter le test et le débogage d’un titre. Pilote retail : optimisé pour les performances, et non pour l’instrumentation ou le débogage. Il ne vérifie pas l’exactitude des paramètres. Des paramètres incorrects transmis au pilote retail risquent de provoquer des corruptions, des plantages ou des blocages du GPU. Les titres ne peuvent être commercialisés qu’avec le pilote retail. Les autres pilotes (instrumenté et de débogage) ne sont présents que sur les kits de développement. Pilote instrumenté : active l’instrumentation PIX. Relativement léger. Peut être utilisé pour faciliter le débogage des problèmes de synchronisation et d’autres problèmes de timing. Il ne vérifie pas l’exactitude des paramètres. Pilote de débogage : effectue des tests de validation sur les paramètres transmis aux appels d’API, ce qui peut aider à déboguer les problèmes d’exactitude et de performances. Toutefois, les bogues de timing peuvent ne pas être reproduits avec le pilote de débogage, car le traitement de validation affecte les performances d’exécution. Pour ajuster le niveau de validation, appelez ID3D12Device::SetDebugFlagsX. Pour sélectionner le pilote utilisé, appelez l’une des méthodes suivantes.

Objets d’état de pipeline (PSO) hors connexion et dérivés

Un objet d’état de pipeline (PSO) hors connexion permet d’améliorer considérablement les performances par rapport à la création de l’état de pipeline au moment de l’exécution, en encapsulant l’état de pipeline (y compris les shaders) dans un objet unique qui peut être chargé et défini rapidement. Un PSO hors connexion stocke l’état des shaders précompilés, de la cible de rendu et du stencil de profondeur. Les objets PSO hors connexion sont stockés sur disque, puis chargés par l’application lorsque cela est nécessaire. Sur PC, il existe un système similaire mais pas identique appelé mise en cache des PSO. Pour créer des objets PSO hors connexion, utilisez l’outil PSO (fourni en tant qu’exemple du Microsoft Game Development Kit (GDK) situé dans le dossier \bin du GXDK), ou écrivez votre propre outil utilisant les API de sérialisation de l’état de pipeline, répertoriées ci-dessous.

API pour les PSO hors connexion

Les API suivantes manipulent les PSO hors connexion.
  • ID3D12Device::SerializeGraphicsPipelineStateX : cette méthode sérialise un PSO afin de permettre un chargement efficace au moment de l’exécution. Elle est destinée à être appelée dans le cadre d’un processus de création de contenu hors connexion, exécuté sur un PC (pris en charge par le pilote umd12_pc.dll ou xgs12_pc_xs.dll), et n’est pas destinée à être appelée pendant l’exécution d’un titre.
  • ID3D12Device::DeserializeGraphicsPipelineStateX : cette méthode désérialise (charge) un PSO graphique précédemment sérialisé. Cette méthode ne déclenche jamais de compilation de shaders au moment de l’exécution, bien que, dans de rares cas, elle génère une erreur indiquant que d’anciens PSO doivent être recompilés.
  • D3D12XBOX_SERIALIZE_SHADER : cette structure contient des pointeurs vers les instructions GPU sérialisées du shader et éventuellement des métadonnées sérialisées.
  • D3D12XBOX_DESERIALIZE_SHADER : cette structure contient des pointeurs vers les instructions GPU brutes désérialisées du shader et les métadonnées désérialisées.
  • D3D12XBOX_SERIALIZE_FLAGS : cette énumération définit les indicateurs de sérialisation.
  • D3D12XBOX_SERIALIZE_GRAPHICS_PIPELINE_STATE : cette structure contient l’état de pipeline sérialisé.
  • D3D12XBOX_DESERIALIZE_GRAPHICS_PIPELINE_STATE : cette structure contient l’état de pipeline désérialisé.

PSO dérivés

 Étant donné le nombre de changements d’état de pipeline, plus important que ce dont une application a probablement besoin, il n’est pas judicieux de créer des PSO hors connexion pour chaque variante. Créez plutôt un PSO hors connexion pour un état de base couramment utilisé, puis utilisez des PSO dérivés pour apporter des modifications limitées au PSO hors connexion. Les modifications apportées au PSO hors connexion ne peuvent pas impliquer de changements du shader ou de la cible de rendu. Pour un jeu typique, la majorité des objets PSO doivent être créés hors connexion, les permutations étant effectuées au moment de l’exécution à l’aide des API suivantes. Si le PSO source a été créé en appelant ID3D12Device::DeserializeGraphicsPipelineStateX, il incombe à l’application de s’assurer que les instructions GPU persistent pendant toute la durée de vie de l’objet d’origine et de l’objet dérivé. Si le PSO source a été créé à l’aide de la méthode Direct3D 12 standard ID3D12Device::CreateGraphicsPipelineState, Direct3D 12.x ajoute automatiquement une référence à l’objet source afin de garantir que ses instructions GPU persistent pendant toute la durée de vie de l’objet dérivé.

Exemples illustrant les PSO hors connexion et les PSO dérivés

L’exemple Direct3D 12.x Deferred Context utilise des PSO hors connexion et des PSO dérivés. Les exemples Direct3D 12.x suivants utilisent des PSO hors connexion.
  • Bokeh Effect
  • Compute Particles
  • Deferred Particles
  • Draw Bundles
  • Dynamic Cube Map
  • ESRAM
  • Mesh Rendering
  • Simple Bezier
  • Simple Instancing
  • Simple Lighting
  • Simple Triangle
Pour plus d’informations, consultez la rubrique Liste des exemples du Microsoft Game Development Kit.

Tas de descripteurs

Sur PC Windows, les tas de descripteurs créés avec D3D12_DESCRIPTOR_HEAP_FLAG_SHADER_VISIBLE ne peuvent pas être utilisés comme source pour les copies de descripteurs. Sur le Microsoft Game Development Kit (GDK), les copies de descripteurs créées avec ID3D12Device::CopyDescriptors et ID3D12Device::CopyDescriptorsSimple prennent en charge tous les tas de descripteurs comme tas source, et la copie est effectuée via une vue en lecture seule mise en cache et efficace du tas source.

Création de ressources

Les ressources d’arguments indirects doivent spécifier D3D12XBOX_RESOURCE_FLAG_ALLOW_INDIRECT_BUFFER au moment de la création de la ressource. Les ressources dotées de cet indicateur doivent être mises en transition vers l’état de ressource D3D12_RESOURCE_STATE_INDIRECT_ARGUMENT. D3D12_RESOURCE_STATE_INDIRECT_ARGUMENT n’est pas inclus dans l’état de ressource combiné D3D12_RESOURCE_STATE_GENERIC_READ sur le Game OS du Microsoft GDK. Sur le Game OS du Microsoft GDK, D3D12_RESOURCE_STATE_GENERIC_READ est déclaré comme suit :
En revanche, sur Direct3D 12/PC, D3D12_RESOURCE_STATE_GENERIC_READ est déclaré de façon à inclure D3D12_RESOURCE_STATE_INDIRECT_ARGUMENT, en plus des valeurs mentionnées précédemment. Pour plus d’informations, consultez D3D12_RESOURCE_FLAGS et D3D12_RESOURCE_STATES.

Barrières de ressources

Une barrière de ressources indique au pilote qu’une synchronisation de plusieurs accès à une même ressource peut être nécessaire, par exemple pour synchroniser la lecture et l’écriture d’une même texture. La version GXDK du Game OS du Microsoft GDK de ID3D12GraphicsCommandList::ResourceBarrier prend en charge la combinaison des indicateurs D3D12_RESOURCE_STATE_COPY_SOURCE et D3D12_RESOURCE_STATE_COPY_DEST, afin de prendre en charge les copies intra-ressource. Les copies intra-ressource sont celles dont la source et la destination se trouvent dans la même sous-ressource de la même ressource.

API pour les barrières de ressources

Sur le Game OS du Microsoft GDK, les barrières de ressources sont implémentées en appelant les méthodes suivantes.

Barrières de ressources lors des transitions d’utilisation

Sur PC Windows, les barrières de ressources peuvent effectuer des mises en veille conservatrices du GPU ainsi que le vidage/l’invalidation des caches. En revanche, sur le Game OS du Microsoft GDK, les barrières de ressources effectuent une synchronisation, une invalidation et une décompression conservatrices lors des transitions d’utilisation. Dans le cadre de cette différence, il existe des indicateurs de création de ressources propres à XBOX, recommandés mais non indispensables.
  • D3D12XBOX_RESOURCE_FLAG_PREFER_INDEX_BUFFER
  • D3D12XBOX_RESOURCE_FLAG_PREFER_INDIRECT_BUFFER
  • D3D12XBOX_RESOURCE_FLAG_PREFER_PREDICATION_BUFFER
  • D3D12XBOX_RESOURCE_FLAG_PREFER_STREAM_OUTPUT
  • D3D12XBOX_RESOURCE_FLAG_DENY_COMPRESSION_DATA
Ces indicateurs sont des extensions Direct3D 12.x du Game OS du Microsoft GDK, sous forme de constantes de l’énumération D3D12_RESOURCE_FLAGS.

Utilisation directe des ressources compressées

Les types d’utilisation de ressources suivants empêchent la décompression lors des transitions de barrières de ressources et permettent de consommer les ressources dans un état compressé.
  • D3D12XBOX_RESOURCE_STATE_PRESERVE_COMPRESSED_COLOR
  • D3D12XBOX_RESOURCE_STATE_PRESERVE_COMPRESSED_DEPTH
  • D3D12XBOX_RESOURCE_STATE_PRESERVE_COMPRESSED_STENCIL
  • D3D12XBOX_RESOURCE_STATE_PRESERVE_COMPRESSED_DEPTH_STENCIL
  • D3D12XBOX_RESOURCE_STATE_PRESERVE_INDIRECT_COLOR_CLEAR
  • D3D12XBOX_RESOURCE_STATE_PRESERVE_SCATTERED_COLOR_FMASK
Il existe un ensemble correspondant d’indicateurs PRESERVE_EXPANDED qui, en tant qu’équivalents des indicateurs PRESERVE_COMPRESSED, servent à maintenir les ressources dans un état décompressé après une transition qui réactiverait normalement leur compression.
  • D3D12XBOX_RESOURCE_STATE_PRESERVE_EXPANDED_COLOR
  • D3D12XBOX_RESOURCE_STATE_PRESERVE_EXPANDED_DEPTH
  • D3D12XBOX_RESOURCE_STATE_PRESERVE_EXPANDED_STENCIL
  • D3D12XBOX_RESOURCE_STATE_PRESERVE_EXPANDED_DEPTH_STENCIL
Par exemple, D3D12XBOX_RESOURCE_STATE_PRESERVE_EXPANDED_COLOR pourrait être utilisé lors du passage d’un état de lecture sur une ressource multi-échantillonnée à un état D3D12_RESOURCE_STATE_RENDER_TARGET, afin d’empêcher que les nouvelles écritures dans la cible soient stockées sous forme compressée. Ces deux ensembles d’indicateurs sont des extensions Direct3D 12.x du Game OS du Microsoft GDK, sous forme de constantes de l’énumération D3D12_RESOURCE_STATES propres au Game OS du Microsoft GDK.

Barrières pour les transitions entre des états d’utilisation qui incluent ou non l’accès en écriture

Sur le Game OS du Microsoft GDK, l’approche recommandée pour effectuer les transitions de barrières, au-delà de l’approche de Direct3D 12/PC, consiste à identifier les barrières qui impliquent une transition depuis des états d’utilisation incluant l’accès en écriture vers des états d’utilisation n’incluant pas l’accès en écriture. Lorsqu’elles sont effectuées sur D3D12_RESOURCE_BARRIER_ALL_SUBRESOURCES, ces barrières doivent être divisées en une barrière fractionnée, avec un appel BEGIN_ONLY et un appel END_ONLY, lorsque du travail GPU indépendant est disponible pour exécution, comme suit.
  1. D3D12_RESOURCE_BARRIER_FLAG_BEGIN_ONLY est utilisé pour démarrer une transition de barrière vers un nouvel état (sans la terminer), ce qui place la ressource dans une condition temporaire sans accès.
  2. Ajoutez le travail indépendant à la liste de commandes.
  3. D3D12_RESOURCE_BARRIER_FLAG_END_ONLY est utilisé dans un appel ResourceBarrier ultérieur pour terminer la transition et passer de la condition temporaire sans accès et de l’ancien état à un accès actif dans le nouvel état.
Les indicateurs BEGIN/END peuvent être utilisés avec le type D3D12_RESOURCE_BARRIER_TYPE_UAV. D3D12_RESOURCE_BARRIER_ALL_SUBRESOURCES, mentionné précédemment, est une valeur #define pour Direct3D 12.x et Direct3D 12/PC. Consultez D3D12_RESOURCE_BARRIER_FLAGS.

Différences d’alignement

L’alignement du pas de ligne (row pitch) sur le Game OS du Microsoft GDK est de 1 024 octets, et non de 512 octets comme sur PC (cela est défini en affectant la valeur 1024 à D3D12XBOX_TEXTURE_DATA_PITCH_ALIGNMENT). En outre, l’exigence du PC selon laquelle les tampons doivent être alignés sur 64 Ko/4 Mo ne s’applique pas à XBOX, même si le code de validation peut encore afficher une erreur si ces alignements ne sont pas respectés. L’alignement par défaut des tampons de constantes est de 16 octets, au lieu de 256 octets sur PC. Cet alignement est spécifié par la constante D3D12_CONSTANT_BUFFER_DATA_PLACEMENT_ALIGNMENT.

Voir aussi

d3d12x
Last modified on October 6, 2026