Gestion de l’état des pipelines graphiques dans Direct3D 12

Cette rubrique décrit comment l’état du pipeline graphique est défini dans Direct3D 12.

Vue d’ensemble de l’état du pipeline

Lorsque la géométrie est envoyée à l’unité de traitement graphique (GPU) à dessiner, il existe un large éventail de paramètres matériels qui déterminent la façon dont les données d’entrée sont interprétées et rendues. Collectivement, ces paramètres sont appelés état du pipeline graphique et incluent des paramètres courants tels que l’état de rastériseur, l’état de fusion et l’état du gabarit de profondeur, ainsi que le type de topologie primitive de la géométrie soumise et les nuanceurs qui seront utilisés pour le rendu. Dans Microsoft Direct3D 12, l’état de la plupart des pipelines graphiques est défini à l’aide d’objets d’état de pipeline (PSO). Une application peut créer un nombre illimité de ces objets, représentés par l’interface ID3D12PipelineState , généralement au moment de l’initialisation. Ensuite, au moment du rendu, les listes de commandes peuvent rapidement basculer plusieurs paramètres de l’état du pipeline en appelant ID3D12GraphicsCommandList::SetPipelineState dans une liste de commandes directe ou un bundle pour définir l’authentification unique active.

Dans Direct3D 11, l’état du pipeline graphique a été regroupé dans des objets à l’état grossier, comme ID3D11BlendState , qui pouvaient être créés et définis au moment du rendu dans le contexte immédiat avec des méthodes telles que ID3D11DeviceContext::OMSetBlendState. L’idée sous-jacente était que le GPU pouvait gagner en efficacité en définissant les paramètres associés, comme les paramètres d’état de fusion, en même temps. Toutefois, avec le matériel graphique d’aujourd’hui, il existe des dépendances entre les différentes unités matérielles. Par exemple, l’état de fusion matérielle peut avoir des dépendances sur l’état raster ainsi que sur l’état de fusion. Les OSP dans Direct3D 12 ont été conçus pour permettre au GPU de prétraiter tous les paramètres dépendants dans chaque état de pipeline, généralement pendant l’initialisation, afin de rendre le basculement entre les états au moment du rendu aussi efficace que possible.

Notez que bien que la plupart des paramètres d’état du pipeline soient définis à l’aide de psos, certains paramètres d’état sont définis séparément à l’aide d’API fournies par ID3D12GraphicsCommandList. Ces paramètres et les API associées sont décrits en détail ci-dessous. En outre, il existe des différences dans la façon dont l’état du pipeline graphique est hérité et conservé à partir des listes de commandes directes et des bundles. Cette rubrique fournit des détails sur ces deux éléments ci-dessous.

États de pipeline graphiques définis avec des objets d’état de pipeline

Le moyen le plus simple de voir tous les différents états de pipeline qui peuvent être définis à l’aide d’un objet d’état de pipeline consiste à examiner la rubrique de référence pour l’D3D12_GRAPHICS_PIPELINE_STATE_DESC que vous passez à ID3D12Device::CreateGraphicsPipelineState lorsque vous initialisez l’objet. Voici un résumé rapide des états qui peuvent être définis :

• Bytecode pour tous les nuanceurs, y compris les nuanceurs de vertex, de pixels, de domaine, de coque et de géométrie.
• Format de vertex d’entrée.
• Type de topologie primitive. Notez que le type de topologie primitive d’assembleur d’entrée (point, ligne, triangle, patch) est défini dans l’authentification unique à l’aide de l’énumération D3D12_PRIMITIVE_TOPOLOGY_TYPE . L’adjacence primitive et l’ordre (liste de lignes, bande de lignes, bande de lignes avec des données d’adjacence, etc.) sont définis à partir d’une liste de commandes à l’aide de la méthode ID3D12GraphicsCommandList::IASetPrimitiveTopology .
• État de fusion, état de rastériseur, état de gabarit de profondeur.
• Gabarit de profondeur et formats cibles de rendu, ainsi que le nombre de cibles de rendu.
• Paramètres d’échantillonnage multiple.
• Mémoire tampon de sortie de streaming.
• Signature racine. Pour plus d’informations, consultez Signatures racines.

États de pipeline graphiques définis en dehors de l’objet d’état du pipeline

La plupart des états de pipeline graphique sont définis à l’aide d’OSS. Toutefois, il existe un ensemble de paramètres d’état de pipeline qui sont définis en appelant des méthodes de l’interface ID3D12GraphicsCommandList à partir d’une liste de commandes. Le tableau suivant montre les états qui sont définis de cette façon et les méthodes correspondantes.

Héritage de l’état du pipeline graphique

Étant donné que les listes de commandes directes sont généralement destinées à une utilisation à la fois et que les offres groupées sont destinées à être utilisées plusieurs fois simultanément, il existe différentes règles sur la façon dont elles héritent de l’état de pipeline graphique qui a été défini par les listes de commandes ou les offres groupées précédentes.

Pour les états de pipeline graphique qui sont définis à l’aide d’OSP, aucun de ces états n’est hérité par des listes de commandes directes ou des bundles. L’état initial du pipeline graphique pour les listes de commandes directes et les bundles est défini au moment de la création avec le paramètre ID3D12PipelineState sur ID3D12Device::CreateCommandList. Si aucun psO n’est spécifié dans l’appel, un état initial par défaut est utilisé. Vous pouvez modifier l’authentification unique actuelle dans une liste de commandes en appelant ID3D12GraphicsCommandList::SetPipelineState.

Les listes de commandes directes n’héritent pas non plus de l’état défini avec des méthodes de liste de commandes telles que RSSetViewports. Pour plus d’informations sur les valeurs initiales par défaut pour les états non-PSO, consultez ID3D12GraphicsCommandList::ClearState.

Les bundles héritent de tous les états de pipeline graphique qui n’est pas défini avec les oss, à l’exception du type de topologie primitive. La topologie primitive est toujours définie sur D3D12_PRIMITIVE_TOPOLOGY_TYPE_UNDEFINED lorsqu’un bundle commence à s’exécuter. Tout état défini dans un bundle (le psO lui-même, l’état non basé sur l’authentification unique et les liaisons de ressources) affecte l’état de sa liste de commandes directes parente. Par exemple, si un RSSetViewports est appelé à partir d’un bundle, les fenêtres d’affichage spécifiées continueront d’être définies dans la liste de commandes directes parente pour les appels consécutifs à l’appel ExecuteBundle qui définit les fenêtres d’affichage.

Les liaisons de ressources définies dans une liste de commandes ou un bundle sont conservées. Par conséquent, les liaisons de ressources modifiées dans une liste de commandes directes seront toujours définies lors de l’exécution de bundle enfant ultérieure. Et les liaisons de ressources modifiées à partir d’un bundle seront toujours définies pour les appels suivants dans la liste de commandes directes parentes.

Pour plus d’informations sur les liaisons, reportez-vous à la section Sémantique de l’offre groupée de l’article Utilisation d’une signature racine.

Rubriques connexes

• Envoi de travail dans Direct3D 12