Utilisation avancée des tables de descripteurs

  • Article

Les sections suivantes fournissent des informations sur l’utilisation avancée des tables de descripteurs.

Modification des entrées de table de descripteur entre des appels de rendu

Une fois que les listes de commandes qui définissent des tables de descripteurs ont été envoyées à une file d’attente pour exécution, l’application ne doit pas modifier à partir du processeur les parties des tas de descripteurs que le GPU peut référencer tant que l’application ne sait pas que le GPU a fini d’utiliser les références.

L’achèvement du travail peut être déterminé à une limite étroite à l’aide de clôtures d’API pour suivre la progression du GPU, ou de mécanismes plus grossières tels que l’attente de voir que le rendu a été envoyé à l’affichage - quel que soit l’application. Si une application sait que seul un sous-ensemble de la région vers laquelle pointe une table de descripteur est accessible (par exemple, en raison du contrôle de flux dans le nuanceur), les autres descripteurs non référencés sont toujours libres d’être modifiés. Si une application doit basculer entre différentes tables de descripteurs entre les appels de rendu, l’application peut choisir quelques approches :

  • Contrôle de version de la table de descripteur : créez (ou réutilisez) une table de descripteur distincte pour chaque collection unique de descripteurs qui doit être référencée par une liste de commandes. Lors de la modification et de la réutilisation de zones précédemment remplies sur des tas de descripteurs, les applications doivent d’abord s’assurer que le GPU a fini d’utiliser n’importe quelle partie d’un tas de descripteur qui sera recyclée.
  • Indexation dynamique : les applications peuvent organiser des objets qui varient d’un dessin à l’autre (ou même varier au sein d’un dessin) dans une plage d’un tas de descripteurs, définir une table de descripteur qui les couvre tous et, à partir du nuanceur, utiliser l’indexation dynamique de la table pendant l’exécution du nuanceur pour sélectionner l’objet à utiliser.
  • Placer directement des descripteurs dans la signature racine. Seul un très petit nombre de descripteurs peut être géré de cette façon, car l’espace de signature racine est limité.

L’utilisation du contrôle de version de table de descripteur implique que la mémoire du descripteur d’un tas de descripteurs doit être brûlée pour chaque ensemble unique de descripteurs référencé par le pipeline graphique pour chaque liste de commandes qui peut être exécutée, mise en file d’attente pour l’exécution ou en cours d’enregistrement à un moment donné.

D3D12 laisse la responsabilité de la gestion du contrôle de version à l’application pour les types d’objets gérés via des tas de descripteurs et des tables de descripteurs. L’un des avantages est que les applications peuvent choisir de réutiliser autant que possible le contenu de la table de descripteur au lieu de toujours définir une nouvelle version de table de descripteur pour chaque envoi de liste de commandes. La signature racine est un espace que le pilote D3D12 versionne automatiquement.

La possibilité de lier plusieurs tables de descripteurs à la signature racine (et donc au pipeline) à la fois permet aux applications de regrouper et de changer d’ensembles de références de descripteurs à différentes fréquences si vous le souhaitez. Par exemple, une application peut utiliser un petit nombre (peut-être une seule) de grandes tables de descripteurs statiques qui changent rarement, ou dans quelles régions de la mémoire du tas de descripteur sous-jacent sont remplies en fonction des besoins, avec l’utilisation d’une indexation dynamique à partir du nuanceur pour sélectionner des textures. En même temps, l’application peut gérer une autre classe de ressources où le jeu référencé par chaque appel de dessin est commuté à partir du processeur à l’aide de la technique de contrôle de version de la table de descripteur.

Indexation hors limites

L’indexation hors limites d’une table de descripteur à partir du nuanceur entraîne un accès à la mémoire largement non défini, y compris la possibilité de lire la mémoire in-process arbitraire comme s’il s’agit d’un descripteur d’état matériel et de vivre avec la conséquence de ce que le matériel en fait. Cela peut produire une réinitialisation de l’appareil, mais ne bloque pas Windows.

Dérivés du nuanceur et indexation divergente

Si les appels de nuanceur de pixels qui s’exécutent dans un tampon 2x2 (pour prendre en charge les calculs dérivés) choisissent différents index de texture à échantillonner à partir d’une table de descripteur, et si la configuration et la texture de l’échantillonneur sélectionnés pour un pixel donné nécessitent un calcul LOD à partir de dérivés de coordonnées de texture, le calcul LOD et le processus d’échantillonnage de texture sont effectués par le matériel indépendamment pour chaque recherche de texture dans le tampon 2x2, ce qui aura un impact sur les performances.

Tables de descripteurs