Partager via

Utilisation d’une signature racine

  • Article

La signature racine est la définition d’une collection arbitrairement organisée de tables de descripteurs (y compris leur disposition), de constantes racines et de descripteurs racines. Chaque entrée a un coût par rapport à une limite maximale, de sorte que l’application peut équilibrer le nombre de chaque type d’entrée que la signature racine contiendra.

La signature racine est un objet qui peut être créé par spécification manuelle au niveau de l’API. Tous les nuanceurs d’un psO doivent être compatibles avec la disposition racine spécifiée avec le psO, sinon les nuanceurs individuels doivent inclure des dispositions racines incorporées qui correspondent les unes aux autres ; sinon, la création d’une authentification unique échouera. Une propriété de la signature racine est que les nuanceurs n’ont pas besoin d’en savoir lors de sa création, bien que les signatures racines puissent également être créées directement dans les nuanceurs si vous le souhaitez. Les ressources de nuanceur existantes ne nécessitent aucune modification pour être compatibles avec les signatures racines. Le modèle de nuanceur 5.1 est introduit pour offrir une flexibilité supplémentaire (indexation dynamique des descripteurs à partir de nuanceurs) et peut être adopté de manière incrémentielle à partir des ressources de nuanceur existantes selon vos besoins.

Sémantique de liste de commandes

Au début d’une liste de commandes, la signature racine n’est pas définie. Les nuanceurs graphiques ont une signature racine distincte du nuanceur de calcul, chacun étant attribué indépendamment dans une liste de commandes. Le jeu de signature racine sur une liste de commandes ou un bundle doit également correspondre à l’authentification unique actuellement définie sur Draw/Dispatch ; sinon, le comportement n’est pas défini. Les incompatibilités temporaires de signature racine avant Draw/Dispatch sont correctes, telles que la définition d’un bloc d’alimentation incompatible avant de passer à une signature racine compatible (tant que celles-ci sont compatibles au moment de l’appel de Draw/Dispatch). La définition d’un bloc d’alimentation ne modifie pas la signature racine. L’application doit appeler une API dédiée pour définir la signature racine.

Une fois qu’une signature racine a été définie sur une liste de commandes, la disposition définit l’ensemble des liaisons que l’application est censée fournir, et les osSP qui peuvent être utilisés (ceux compilés avec la même disposition) pour les appels de dessin/distribution suivants. Par exemple, une signature racine peut être définie par l’application pour avoir les entrées suivantes. Chaque entrée est appelée « emplacement ».

  • [0] Un descripteur CBV inline (descripteurs racine)
  • [1] Table de descripteur contenant 2 VSR, 1 CBV et 1 UAV
  • [2] Table de descripteur contenant 1 échantillonneur
  • [3] Collection 4x32 bits de constantes racines
  • [4] Table de descripteur contenant un nombre non spécifié de SSV

Dans ce cas, avant de pouvoir émettre un draw/dispatch, l’application doit définir la liaison appropriée sur chacun des emplacements [0..4] définis par l’application avec sa signature racine actuelle. Pour instance, à l’emplacement [1], une table de descripteur doit être liée, c’est-à-dire une région contiguë dans un tas de descripteurs qui contient (ou contiendra au moment de l’exécution) 2 SRV, 1 CBV et 1 UAV. De même, les tables de descripteurs doivent être définies aux emplacements [2] et [4].

L’application peut modifier une partie des liaisons de signature racine à la fois (le reste reste inchangé). Par exemple, si la seule chose qui doit changer entre les dessins est l’une des constantes à l’emplacement [2], c’est tout ce que l’application a besoin de rebiner. Comme indiqué précédemment, le pilote/le matériel version tous les états de liaison de signature racine, car il est modifié automatiquement. Si une signature racine est modifiée dans une liste de commandes, toutes les liaisons de signature racine précédentes deviennent obsolètes et toutes les liaisons nouvellement attendues doivent être définies avant Draw/Dispatch ; sinon, le comportement n’est pas défini. Si la signature racine est définie de manière redondante sur la même que celle actuellement définie, les liaisons de signature racine existantes ne deviennent pas obsolètes.

Sémantique des bundles

Les bundles héritent des liaisons de signature racine de la liste de commandes (les liaisons aux différents emplacements dans l’exemple de liste de commandes ci-dessus). Si un bundle doit modifier certaines des liaisons de signature racine héritées, il doit d’abord définir la signature racine pour qu’elle soit identique à la liste de commandes appelante (les liaisons héritées ne deviennent pas obsolètes). Si le bundle définit la signature racine pour qu’elle soit différente de la liste de commandes appelante, cela a le même effet que la modification de la signature racine dans la liste de commandes décrite ci-dessus : toutes les liaisons de signature racine précédentes sont obsolètes et les liaisons nouvellement attendues doivent être définies avant Draw/Dispatch ; sinon, le comportement n’est pas défini. Si un bundle n’a pas besoin de modifier les liaisons de signature racine, il n’a pas besoin de définir la signature racine.

Le code suivant montre un exemple de flux d’appels dans un bundle.

// Command List
...
pCmdList->SetGraphicsRootSignature(pRootSig); // new parameter space
MyEngine_SetTextures(); // bundle inherits descriptor table setting
MyEngine_SetAnimationFactor(fTime); // bundle inherits root constant
pCmdList->ExecuteBundle(...);
...
// Bundle
pBundle->SetGraphicsRootSignature(pRootSig); // same as caller, in order to inherits bindings
pBundle->SetPipelineState(pPS); 
pBundle->SetGraphicsRoot32BitConstant(drawConstantsSlot,0,drawIDOffset);
pBundle->Draw(...); // using inherited textures / animation factor
pBundle->SetGraphicsRoot32BitConstant(drawConstantsSlot,1,drawIDOffset);
pBundle->Draw(...);
...

À partir d’un bundle, toutes les modifications de disposition racine et/ou de liaison apportées par un bundle sont héritées de la liste des commandes appelantes quand l’exécution d’un bundle est terminée.

Pour plus d’informations sur l’héritage, reportez-vous à la section Héritage de l’état du pipeline Graphics de Gestion de l’état du pipeline graphics dans Direct3D 12.

Signatures racine