Partager via

Vue d’ensemble des tas de descripteurs

  • Article

Les tas de descripteurs contiennent de nombreux types d’objets qui ne font pas partie d’un objet d’état de pipeline (PSO), tels que les vues de ressources de nuanceur (SRV), les vues d’accès non ordonnées (UAV), les vues de mémoire tampon constante (CBV) et les échantillonneurs.

L’objectif des tas de descripteurs

L’objectif principal d’un tas de descripteur est d’englober la majeure partie de l’allocation de mémoire requise pour stocker les spécifications de descripteur des types d’objets que les nuanceurs référencent pour une fenêtre de rendu aussi grande que possible (idéalement un cadre entier de rendu ou plus). Si une application change les textures que le pipeline voit rapidement à partir de l’API, il doit y avoir de l’espace dans le tas de descripteur pour définir les tables de descripteurs à la volée pour chaque ensemble d’état nécessaire. L’application peut choisir de réutiliser des définitions si les ressources sont à nouveau utilisées dans un autre objet, par exemple, ou simplement d’affecter l’espace du tas de manière séquentielle à mesure qu’il bascule différents types d’objets.

Les tas de descripteurs permettent également à des composants logiciels individuels de gérer le stockage de descripteurs séparément les uns des autres.

Tous les tas sont visibles par le processeur. L’application peut également demander quelles propriétés d’accès au processeur un tas de descripteur doit avoir (le cas échéant) : écriture combinée, écriture différée, etc. Les applications peuvent créer autant de tas de descripteurs que vous le souhaitez avec les propriétés souhaitées. Les applications ont toujours la possibilité de créer des tas de descripteurs qui sont uniquement destinés à des fins intermédiaires qui ne sont pas contraintes en taille, et de copier dans des tas de descripteurs qui sont utilisés pour le rendu si nécessaire.

Il existe certaines restrictions dans ce qui peut aller dans le même tas de descripteur. Les entrées CBV, UAV et SRV peuvent se trouver dans le même tas de descripteur. Toutefois, les entrées Samplers ne peuvent pas partager un tas avec des entrées CBV, UAV ou SRV. En règle générale, il existe deux ensembles de tas de descripteurs, l’un pour les ressources communes et l’autre pour les échantillonneurs.

L’utilisation de tas de descripteurs par Direct3D 12 reflète ce que fait la plupart du matériel GPU, soit exiger que les descripteurs vivent uniquement dans les tas de descripteurs, soit simplement que moins de bits d’adressage sont nécessaires si ces tas sont utilisés. Direct3D 12 nécessite l’utilisation de tas de descripteurs. Il n’existe aucune option permettant de placer des descripteurs n’importe où en mémoire.

Les tas de descripteurs ne peuvent être modifiés immédiatement que par le processeur. Il n’existe aucune option permettant de modifier un tas de descripteur par le GPU.

Synchronization

Le contenu du tas de descripteur peut être modifié avant, pendant et après l’enregistrement des listes de commandes qui le référencent. Toutefois, les descripteurs ne peuvent pas être modifiés alors qu’une liste de commandes envoyée pour exécution peut référencer cet emplacement, car cela peut appeler une condition de concurrence.

Liaison

Au plus un tas combiné CBV/SRV/UAV et un tas sampler peuvent être liés à tout moment. Ces tas sont partagés entre les pipelines graphiques et de calcul (décrits dans leurs osS).

Changement de segments de mémoire

Il est acceptable qu’une application change de tas au sein de la même liste de commandes ou dans d’autres à l’aide des API SetDescriptorHeaps et Reset . Sur certains matériels, il peut s’agir d’une opération coûteuse, nécessitant un blocage gpu pour vider tout le travail qui dépend du tas de descripteur actuellement lié. Par conséquent, si les tas de descripteurs doivent être modifiés, les applications doivent essayer de le faire lorsque la charge de travail GPU est relativement légère, ce qui peut limiter les modifications au début d’une liste de commandes.

Packs

Avec les bundles, il ne peut y avoir qu’un seul appel à la méthode SetDescriptorHeaps , et les tas de descripteurs définis doivent correspondre exactement à ceux de la liste de commandes appelant le bundle. Si le bundle ne modifie pas les tables de descripteurs, il n’a pas besoin de définir les tas de descripteurs.

Pour obtenir la liste des appels d’API qui ne peuvent pas être utilisés avec des bundles, reportez-vous à Création et enregistrement de listes de commandes et d’ensembles.

Gestion

Pour afficher tous les objets d’une scène, de nombreux descripteurs sont nécessaires, et il existe différentes stratégies de gestion qui peuvent être suivies.

La stratégie la plus simple consiste à remplir une nouvelle zone du tas de descripteur avec toutes les exigences pour le prochain appel au tirage. Ainsi, juste avant d’émettre l’appel de dessin dans la liste de commandes, un pointeur de table de descripteur est défini sur le début de la table fraîchement remplie. L’avantage est qu’il n’est pas nécessaire d’enregistrer où un descripteur particulier se trouve dans le tas.

L’inconvénient de cette stratégie est qu’il pourrait y avoir beaucoup de répétitions de descripteurs dans le tas de descripteur, en particulier lorsqu’une scène très similaire est affichée, et que l’espace du tas de descripteur va être utilisé rapidement. Des tas de descripteurs distincts pour ceux qui sont rendus sur le GPU et pour ceux enregistrés par le processeur, seraient probablement nécessaires pour éviter les conflits. Vous pouvez également utiliser un système de sous-allocation.

En outre, le système de base peut être optimisé en utilisant soigneusement les tables de descripteurs qui se chevauchent d’un appel de dessin à l’autre, de sorte que seuls les nouveaux descripteurs requis sont ajoutés.

Une stratégie plus efficace que la stratégie de base consisterait à pré-remplir les tas de descripteurs avec des descripteurs requis pour les objets (ou les matériaux) connus pour faire partie de la scène. L’idée ici est qu’il n’est nécessaire de définir la table de descripteur qu’au moment du dessin, car le tas de descripteur est rempli à l’avance.

Une variante de la stratégie de pré-remplissage consiste à traiter le tas de descripteur comme un tableau énorme, contenant tous les descripteurs requis dans des emplacements connus fixes. Ensuite, l’appel de dessin n’a besoin que de recevoir un ensemble de constantes qui sont les index dans le tableau de où se trouvent les descripteurs qui doivent être utilisés.

Une autre optimisation consiste à s’assurer que les constantes racines et les descripteurs racine contiennent ceux qui changent le plus fréquemment, plutôt que de placer des constantes dans le tas de descripteur. Pour la plupart des matériels, il s’agit d’un moyen efficace de gérer les constantes.

Dans la pratique, un moteur graphique peut utiliser une stratégie différente dans différentes situations et combiner des éléments de chaque stratégie pour répondre aux exigences de dessin particulières.

Tas de descripteurs