Limites de signature racine
La signature racine est un immobilier de premier choix, et il existe des limites et des coûts stricts à prendre en compte.
Limites et coûts de mémoire
La taille maximale d’une signature racine est de 64 DWORD.
Cette taille maximale est choisie pour éviter toute utilisation abusive de la signature racine comme moyen de stocker des données en bloc. Chaque entrée de la signature racine a un coût pour cette limite de 64 DWORD :
- Les tables de descripteurs coûtent 1 DWORD chacune.
- Les constantes racines coûtent 1 DWORD chacune, car il s’agit de valeurs 32 bits.
- Les descripteurs racines (adresses virtuelles GPU 64 bits) coûtent 2 DWORD chacun.
Les échantillonneurs statiques n’ont aucun coût dans la taille de la signature racine.
Coûts de performances
Le coût de performances (en termes de niveaux d’indirection) est égal à zéro pour une constante racine, 1 pour un descripteur racine et 2 pour une table de descripteur. Si une signature racine est volumineuse et dépasse la mémoire la plus rapide dans une mémoire légèrement plus lente (ce qui peut se produire sur certains matériels), ajoutez 1 au coût de performances pour les éléments qui débordent à la fin de la signature racine.
Un dépassement de capacité peut se produire sur un matériel qui peut avoir, par exemple, une taille fixe de 16 DWORDs pour l’espace d’argument racine. Cette limite peut être réduite d’un seul si l’assembleur d’entrée est utilisé. Dans ce cas, il y a un dépassement de mémoire légèrement plus lent si la signature racine est trop grande pour la mémoire native 15 ou 16 DWORD. Dans d’autres matériels, il n’y a pas de mémoire d’argument racine native fixe (la situation de dépassement de capacité ne se produit donc jamais).
Pour tout le matériel, si un argument racine change, le pilote doit conserver une version de tous les arguments racine (contrairement aux autres stockages tels que les tas de descripteurs et les ressources de mémoire tampon, qui ne sont pas versionnés par le pilote). Dans le matériel où se produit une situation de dépassement de capacité, seule la zone native ou de dépassement doit être versionnée, en fonction de l’emplacement où la modification s’est produite. La quantité de contrôle de version doit évidemment être maintenue au minimum nécessaire.
En règle générale, tenez compte des instructions suivantes :
- Utilisez une petite signature racine si nécessaire, mais équilibrez-la avec la flexibilité d’une signature racine plus grande.
- Organisez les paramètres dans une signature racine volumineuse afin que les paramètres les plus susceptibles de changer souvent, ou si une faible latence d’accès pour un paramètre donné est importante, se produisent en premier.
- Si vous le souhaitez, utilisez des constantes racines ou des vues tampons de constante racine plutôt que de placer des vues de mémoire tampon constante dans un tas de descripteur.
Échantillonneurs statiques
Les échantillonneurs statiques (échantillonneurs où l’état est entièrement défini et immuable) font partie des signatures racines, mais ne comptent pas dans la limite de 64 DWORD. Si un échantillonneur peut être défini comme statique, il n’est pas nécessaire que l’échantillonneur fait partie d’un tas de descripteur.
L’utilisation d’échantillonneurs statiques n’entraîne aucun coût de performances, et une signature racine peut contenir un mélange d’échantillonneurs statiques (stockés dans la signature racine ou dans un espace réservé sur un certain matériel) et d’échantillonneurs dynamiques (stockés dans un tas de descripteur d’échantillonneur). Les échantillonneurs d’un tas de descripteurs peuvent être attribués et indexés dynamiquement, ce que les échantillonneurs statiques ne peuvent pas.
Les échantillonneurs statiques peuvent être écrits dans le cadre de la signature racine dans les nuanceurs HLSL (reportez-vous à Spécification de signatures racines dans HLSL).
Rubriques connexes