Partager via

Limites de signature racine

  • Article

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 DWORDs.

Cette taille maximale est choisie pour empêcher l’abus 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 DWORD de 64 :

  • Les tables de descripteur coûtent 1 DWORD chacun.
  • Les constantes racines coûtent 1 DWORD chacune, car elles sont des 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 des 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 en mémoire légèrement plus lente (ce qui peut se produire sur un matériel), ajoutez 1 au coût de performances pour les éléments de dépassement à la fin de la signature racine.

Un dépassement de capacité peut se produire sur le matériel qui peut avoir, par exemple, une taille fixe de 16 DWORD pour l’espace d’argument racine. Cette limite peut être réduite d’une autre si l’assembleur d’entrée est utilisé. Dans ce cas, il y a un dépassement de capacité en mémoire légèrement plus lente si la signature racine est trop grande pour la mémoire native 15 ou 16 DWORD. Dans d’autres matériels, il n’existe aucune mémoire d’argument racine native fixe (par conséquent, la situation de dépassement de capacité ne se produit jamais).

Pour tout le matériel, si un argument racine change, le pilote doit conserver une version de tous les arguments racine (contrairement à d’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 de capacité doit être versionnée, en fonction de l’endroit où la modification s’est produite. La quantité de contrôle de version doit évidemment être conservée 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 changent souvent, ou si la latence d’accès faible pour un paramètre donné est importante, commencez par se produire.
  • Si c’est pratique, utilisez des constantes racines ou des vues de mémoire tampon de constante racine sur la mise en place de 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 vers 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.

Il n’existe aucun coût de performances pour utiliser des échantillonneurs statiques, 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 matériel) et des échantillonneurs dynamiques (stockés dans un tas de descripteur d’échantillonneur). Les échantillonneurs dans un tas de descripteur peuvent être attribués dynamiquement et indexés, 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 des signatures racines dans HLSL).

signatures racines