Comment fonctionnent les instructions VMEM ?

Cette rubrique explique la classe d’instructions de shader de mémoire vectorielle. Une bonne compréhension du fonctionnement des instructions VMEM est importante pour prendre les bonnes décisions lors du processus d’optimisation des shaders. Cette rubrique est destinée aux programmeurs graphiques et suppose une certaine familiarité avec le GPU XBOX One et DirectX. Pour un rappel, consultez les documents répertoriés dans la section Références. Les instructions de mémoire vectorielle transfèrent une ou plusieurs données de manière unique pour chaque thread de shader d’un wavefront. Dans le GPU XBOX One, elles sont utilisées dans tous les types de shaders pour lire les données de sommets, les données de textures et les données de tampons constants indexés dynamiquement, pour lire et écrire des vues d’accès non ordonné, et pour effectuer des opérations atomiques. Alors que les performances des instructions ALU sont prévisibles, celles des instructions de mémoire vectorielle sont plus complexes et nécessitent de comprendre le fonctionnement de plusieurs modules au sein du GPU. Grâce aux informations contenues dans cette rubrique, vous devriez être en mesure d’analyser le code assembleur des shaders dans PIX et d’appliquer des optimisations mémoire à vos shaders.

Glossaire

Les abréviations et acronymes suivants sont utilisés dans cette rubrique.

CU	Unité de calcul
VALU	Instruction ALU vectorielle
SALU	Instruction ALU scalaire
VMEM	Instruction de mémoire vectorielle
SMEM	Instruction de mémoire scalaire
SQ	Séquenceur
SGPR	GPR scalaire
VGPR	GPR vectoriel
TA	Adressage de texture
TCP	Cache de texture par pipe (cache L1)
TCC	Cache de texture par canal (cache L2)
TD	Données de texture
LDS	Magasin de données local
EXP	Instruction d’exportation de shader
Wave	Un wavefront (vague) est une unité de travail composée de 64 threads de shader
GLC	Globalement cohérent
GDS	Magasin de données global
UAV	Vue d’accès non ordonné

Instructions de tampon et instructions d’image

Les instructions de tampon sont générées pour les opérations de lecture, d’écriture ou atomiques sur des tampons de sommets, des tampons bruts ou des tampons structurés. Aucun filtrage de données ni aucun échantillonneur n’est pris en charge. Les données transitent par les caches L1 et L2, tant pour les lectures que pour les écritures. Il existe deux types d’instructions de tampon : tbuffer_* Instruction de tampon typé. Le format des données est spécifié dans l’instruction et les opérations atomiques ne sont pas prises en charge. buffer_* Instruction de tampon non typé. Le format des données est spécifié dans le descripteur de l’objet tampon. Une conversion de format facultative peut être spécifiée dans les instructions. Les opérations atomiques sont prises en charge. Les instructions d’image sont générées pour les opérations de lecture, d’écriture ou atomiques sur des textures et des surfaces typées. Le filtrage est pris en charge pour la lecture des données. Les données transitent par les caches L1 et L2, tant pour les lectures que pour les écritures. Toutes les instructions d’image disposent d’un champ de masque de données qui spécifie les canaux qu’elles reçoivent. Il existe deux types d’instructions d’image : sample_* Lire et filtrer des données à partir d’une texture. Ces opérations nécessitent un échantillonneur. image_* Lire, écrire ou effectuer une opération atomique sur une texture. Aucun filtrage n’est pris en charge. Il existe d’autres types d’instructions de mémoire vectorielle, mais ils sont relativement rares et ne sont pas abordés dans cette rubrique.

Aide-mémoire : tableau récapitulatif des performances

Il s’agit de valeurs de performances maximales.

Type de lecture	Coût minimal dans les shaders
Lecture de tampon à canal unique	4 cycles
Lecture de tampon multicanal	16 cycles
Opération atomique sur tampon	16 cycles
Fetch de texture à échantillonnage ponctuel	16 cycles, quel que soit le format
Fetch de texture bilinéaire	16 cycles ≤ 32 bpp, 32 cycles 64 bpp, 64 cycles 128 bpp
Fetch de texture trilinéaire	Fetch de texture bilinéaire × 2
Fetch de texture anisotrope xN	(Coût d’un fetch de texture bilinéaire ou d’un fetch de texture trilinéaire) × N

Type de lecture	Vitesse maximale sur l’ensemble du GPU
Lecture de tampon à canal unique	192 valeurs 32 bpp par cycle avec coalescence
Lecture de texture	48 par cycle

Type de lecture	Vitesse maximale en secondes
Lecture ou écriture d’une texture 1080p 32 bpp	50 μs

Ces valeurs sont rarement atteignables en pratique, mais il est utile de les garder en tête pour une analyse rapide d’un shader. Voici quelques règles empiriques rapides qui peuvent être déduites du tableau des performances.

Tout fetch de texture coûte au moins 16 cycles. Rentabilisez-le en lisant autant de données que possible. Gather4 est un outil précieux lorsque vous travaillez avec des textures à canal unique.
Il est parfois moins coûteux de lire une valeur U32 depuis un tampon à l’aide d’une lecture à canal unique et de la décompresser sur l’ALU que de lire 2 à 4 valeurs d’octets distinctes à l’aide d’une lecture multicanal.

Il est impossible de répertorier les performances des instructions de mémoire vectorielle pour un cas général. La latence réelle des instructions de texture est variable et souvent supérieure à 100 cycles d’horloge ; elle avoisine parfois les 400 cycles d’horloge en cas d’échec d’accès au cache (cache miss).

Masquage de la latence

En raison de la latence élevée des instructions de mémoire vectorielle, le GPU utilise deux mécanismes de masquage de la latence. Les instructions de mémoire vectorielle sont conçues pour ne pas bloquer l’exécution du wavefront au moment où elles sont émises. Chaque instruction de mémoire vectorielle émise incrémente un compteur VM, et chaque instruction de mémoire vectorielle retournée décrémente ce compteur. Le compilateur de shaders implémente une synchronisation manuelle en insérant des instructions s_waitcnt avant le point où les résultats sont nécessaires ; sinon, les résultats sont indéfinis. Les instructions de mémoire vectorielle retournent toujours dans l’ordre. Le tableau suivant en présente un exemple.

image_sample v[2:5], v[2:5], s[4:11], s[0:3] dmask:0xf	L’émission de l’instruction commence. Le compteur VM est incrémenté.
v_interp_p1_f32 v6, v0, attr2.wv_interp_p1_f32 v7, v0, attr2.zv_interp_p2_f32 v6, v1, attr2.wv_interp_p1_f32 v8, v0, attr2.yv_interp_p2_f32 v7, v1, attr2.z	L’émission de l’instruction se termine. La vague continue d’exécuter des instructions sans blocage, ce qui réduit essentiellement la latence mémoire. Le compilateur de shaders s’efforce de placer du travail ici.
s_waitcnt vmcnt(0)	C’est ici que la latence se manifeste. Si l’instruction mémoire n’est pas encore retournée, le compteur VM vaut toujours 1 et la vague est mise en mode d’attente.

Si une vague est en mode d’attente, elle ne peut pas poursuivre son exécution tant que le compteur VM est supérieur à la valeur spécifiée dans le paramètre de s_waitcnt. Dans ce cas, la latence est masquée par l’exécution d’autres vagues présentes sur le même SIMD. Plus il y a de vagues disponibles, meilleur est le masquage de la latence. Le nombre de vagues par SIMD est appelé occupation (occupancy), et les développeurs doivent s’efforcer de le maximiser. L’occupation mesurée est visible dans les sections ALU et Performance de la rubrique Dr. PIX, ainsi qu’à l’aide des compteurs de colonnes.

Le même mécanisme s’applique aux instructions LDS, SMEM et EXP/GDS. Toutefois, elles utilisent des compteurs différents.

Vue d’ensemble matérielle d’une unité de texture

Voici une vue d’ensemble schématique de l’unité de texture au sein d’une unité de calcul. Le cache L2 et la mémoire ne sont pas représentés. Figure 1. Vue d’ensemble de haut niveau du TA/TCP/TD

Vue d'ensemble de haut niveau du TA/TCP/TD

Bien qu’il puisse être utile d’employer le terme « unité de texture », cette unité n’existe pas, car le traitement des instructions mémoire est réparti entre au moins trois blocs différents. De plus, ces blocs sont utilisés dans le GPU XBOX One pour lire et écrire les données des tampons de sommets et des UAV. Par conséquent, parler d’« unité de texture » peut prêter à confusion.

Le cycle de vie d’une instruction de mémoire vectorielle

Le coût de chaque instruction VMEM comprend le temps d’émission (SQ->TA), le temps d’émission de la requête mémoire (TA->TCP), le temps de lecture mémoire (TCP->TD) et le temps de retour des données (TD->SQ). Il est possible d’être limité par l’une de ces quatre étapes, bien que les jeux soient le plus souvent limités par l’accès mémoire.

Étape 1 : Émission de l’instruction

Chacune des 12 CU prend en charge jusqu’à 40 vagues. Elles sont réparties en quatre groupes de 10 vagues maximum (un groupe par SIMD) et, à chaque cycle, un SIMD est choisi pour le traitement. Les quatre cycles nécessaires à une CU pour parcourir les quatre SIMD constituent une phase ou un cycle d’attente. À chaque cycle d’horloge, les 10 vagues sont en concurrence pour émettre une instruction de chaque type : VALU, SALU, VMEM, LDS, EXP/GDS et Branch. Pour plus d’informations, consultez le livre blanc Xbox One GPU Shader Cores, disponible en téléchargement sur le site XBOX Game Developer (XGD). Les instructions VMEM utilisent un bus TA unique, partagé par les quatre SIMD. Même si chaque SIMD peut choisir d’émettre une instruction VMEM à chaque cycle d’horloge, le rythme le plus rapide possible est d’une instruction tous les quatre cycles. Pour émettre une instruction VMEM, les opérandes situés dans les SGPR et les VGPR doivent être transférés au TA. Tant que tous les opérandes de l’instruction n’ont pas été transférés au TA, le wavefront émetteur ne peut pas passer à l’instruction suivante, et aucune autre vague de la CU ne peut utiliser le bus TA. L’émission d’instruction VMEM la plus courte prend quatre cycles, d’où la limite du taux d’émission. Les instructions VMEM, comme certains autres types d’instructions, sérialisent essentiellement les wavefronts sur l’ensemble des quatre SIMD. Selon la quantité de données à envoyer, l’émission d’une instruction VMEM prend un nombre variable de cycles d’horloge. C’est logique, car il peut y avoir jusqu’à 64 coordonnées UV, décalages, gradients et autres données différents par instruction. L’émission ne peut donc pas être instantanée. Les opérandes de l’instruction VMEM sont répartis en trois flux et envoyés sur trois bus parallèles : Command, Address et Data. La vitesse d’émission de l’instruction est déterminée par le temps le plus long parmi ces trois bus. Le tableau suivant fournit quelques exemples du temps nécessaire pour émettre une instruction VMEM pour un wavefront, en fonction du nombre et de la taille des opérandes.

Dans l’onglet ALU de Dr.PIX, vous pouvez voir comment ces bus sont utilisés à l’exécution en consultant les statistiques « Time required to issue work on TA ADDR bus » et « Stalled due to full command FIFO »

Opération	Command, cycles	Address, cycles	Data, cycles	Total, cycles
Lecture Image1D, descripteur 128 bits	8 (4 texture + 4 échantillonneur)	4, coordonnée 1D	0, aucune donnée	8
Lecture Image2D, descripteur 256 bits	12 (8 texture + 4 échantillonneur)	8, coordonnée 2D	0, aucune donnée	12
Lecture de tampon	4 (tampon)	4, coordonnée 1D	0, aucune donnée	4
Écriture de tampon à canal unique	4 (tampon)	4, coordonnée 1D	4, 1 DWORD	4
Écriture Image2D	8 (texture)	8, coordonnée 2D	16, 4 DWORD	16

Sur les charges de travail importantes, il n’est possible d’être limité par l’émission des instructions VMEM elle-même que si le temps d’émission dépasse 16 cycles d’horloge. Sinon, c’est généralement le TA qui constitue le goulot d’étranglement. Par exemple, SampleGrad() avec une texture 2D coûtera 24 cycles à émettre et sera environ deux fois plus coûteux qu’un Sample() classique (12 cycles d’horloge) si toutes les lectures atteignent le cache L1. Dans le cas de SampleGrad(), nous pouvons voir dans Dr.PIX les signes révélateurs d’une limitation par l’émission.

Waiting to issue VMEM   80.91, %

VALU                                       259
  Cost per inst                            1, clks
VMEM_RD                                    16
   Cost per inst                           5.999, clks  

D’après ces données, le shader est limité par l’émission VMEM. Le nombre de cycles nécessaires au traitement VMEM est de 384 (16 × 5,99 × 4), ce qui est supérieur au nombre de cycles nécessaires à VALU (259). Une fois l’instruction VMEM émise, le wavefront peut continuer. L’instruction elle-même poursuit alors son exécution dans le bloc TA.

Étape 2 : Calcul des adresses et demande des données

Le TA poursuit l’exécution de l’instruction VMEM en demandant les données au TCP et en informant le TD des données de retour à attendre et de la manière de les filtrer. Le TA peut demander jusqu’à 128 bits de données à partir de quatre emplacements par cycle. La vitesse de lecture maximale du TCP correspond à cette valeur. Cela permet un débit bilinéaire maximal de 2×2 pixels filtrés par cycle pour 32 bpp ou moins, ou un débit non filtré de 4 pixels par cycle jusqu’à 128 bpp. Figure 2. Présentation du processus de fetch de texture à filtrage bilinéaire. Ce processus est répété pour tous les quads du wavefront.

Présentation du processus de fetch de texture à filtrage bilinéaire. Ce processus est répété pour tous les quads du wavefront.

Une instruction VMEM peut déclencher plusieurs requêtes mémoire ; une instruction VMEM ne se retire donc du TA qu’une fois toutes ses requêtes envoyées. C’est ici, par exemple, qu’apparaît d’abord le coût supplémentaire du filtrage trilinéaire et anisotrope. Le TA doit demander au TCP tous les échantillons pour un texel demandé, et certains fetchs devront s’étaler sur de nombreux cycles d’horloge. Le tableau suivant indique les vitesses maximales dans le TA. Il montre le temps nécessaire au TA pour envoyer des requêtes de données au TCP.

Requête	Vitesse	Commentaire
Fetchs à échantillonnage ponctuel	4 pixels/cycle (16 cycles/vague)	Tout format
Fetchs bilinéaires, ≤ 32 bpp	4 pixels/cycle (16 cycles/vague)	≤ 32 bits par pixel à pleine vitesse
Fetchs trilinéaires, ≤ 32 bpp	Bilinéaire / 2	Le GPU tente d’optimiser en bilinéaire lorsque c’est possible.
Anisotrope Nx, ≤ 32 bpp	(Bilinéaire ou trilinéaire) / N	Le tri-juicing est également disponible.*
Bilinéaire, trilinéaire, aniso 64 bpp	Débit 32 bpp / 2
Bilinéaire, trilinéaire, aniso 128 bpp	Débit 32 bpp / 4
Chargement de tampon à canal unique	16 threads/cycle (4 cycles/vague)	Avec coalescence ; 4 threads/cycle sans coalescence.
Chargement de tampon multicanal	4 threads/cycle (16 cycles/vague)
Opérations atomiques sur tampon	4 threads/cycle (16 cycles/vague)

Voici quelques coûts supplémentaires à payer pour les fonctionnalités suivantes (par quad 2×2).

La couleur de bordure ajoute un ou deux cycles.
Les gradients personnalisés ajoutent jusqu’à trois cycles.
Les coins de cubemap peuvent ajouter jusqu’à cinq cycles.
Les cas d’enroulement (wrap) sur des dimensions non puissances de 2 peuvent ajouter jusqu’à trois cycles.

Ce coût cumulé peut provoquer un goulot d’étranglement important à ce stade, car il peut théoriquement atteindre des milliers de cycles par wavefront. Le filtrage anisotrope est le principal exemple où ce coût peut dominer l’exécution du shader. Pour détecter les goulots d’étranglement dus à l’anisotropie, utilisez ce compteur Dr. PIX : Measured duration with anisotropic filtering turned off: 1715040 ns (54% faster) Si cette valeur est élevée, définissez PerfMip pour activer l’optimisation tri-juicing du filtrage trilinéaire ou trilinéaire anisotrope dans ce cas. Cela permettra de basculer vers un filtrage bilinéaire lorsque le LOD de texture est proche d’un entier. Le bloc TA effectue également la coalescence des requêtes de lecture, d’écriture et atomiques à canal unique sur les tampons. Lorsqu’un fetch de tampon à canal unique est utilisé avec des formats de 32 bpp ou moins, une grande partie de la bande passante TCP vers TD risque de rester inutilisée. Pour exploiter cette bande passante, le TA est conçu de sorte que, s’il détecte que les adresses demandées par des threads de shader consécutifs peuvent être lues dans la même requête de 128 bits, il fusionne les lectures et peut retourner jusqu’à 16 éléments par cycle pour les formats à canal unique 8, 16 et 32 bpp. Cela permet des lectures de tampon à canal unique plus rapides, mais uniquement si le TA peut fusionner les lectures de quatre blocs de quatre threads à la fois. Figure 3. Cas fusionnable. Les données de quatre blocs de quatre threads peuvent être lues à partir de quatre emplacements mémoire.

Cas fusionnable. Les données de quatre blocs de quatre threads peuvent être lues à partir de quatre emplacements mémoire.

Figure 4. Cas non fusionnable. Aucun des quatre emplacements ne peut être fusionné.

Le TA traite également l’instruction Gather4. Gather4 permet au TD de retourner des données non filtrées à canal unique pour chacun des 16 texels par cycle. La vitesse par DWORD est la même que celle d’une lecture de tampon fusionnée à canal unique. Prenons par exemple un Gather4 sur une texture R32. Il peut retourner 4 DWORD de données par thread en 16 cycles. Un fetch d’image classique à échantillonnage ponctuel retourne 1 DWORD de données par thread en 16 cycles, soit quatre fois moins de données par cycle. Un fetch à échantillonnage ponctuel pourrait lire une valeur 4×32 par thread si un format R32G32B32A32 était superposé (aliasing) à une texture R32, mais en général cela n’est pas possible en raison des modes de tiling différents entre les formats de texture 128 bpp et 32 bpp.

Étape 3 : Le TCP charge les données et les transmet au TD

Le TCP est le cache « L1 ». Le TCP est propre à chaque CU ; il a une taille de 16 Ko et comporte quatre RAM entrelacées, chacune entièrement associative avec 64 étiquettes et une stratégie LRU. Le TCP stocke des octets de mémoire bruts. Il gère la lecture et l’écriture des données d’image et de tampon, la combinaison des écritures pour les requêtes d’écriture et atomiques, la combinaison des lectures pour les requêtes de lecture, le tiling mémoire et la décompression des formats par blocs à la lecture, ainsi que les textures partiellement résidentes. Le rôle du TCP est de masquer la latence du TCC, et non d’y stocker des données pendant longtemps. Au débit maximal, le TA peut demander quatre adresses uniques par cycle, et le TCP peut retourner au TD jusqu’à 128 bits de données de chaque adresse par cycle. Il est garanti que le TCP peut envoyer au TD n’importe quel texel d’image 2×2 en 1 cycle. Les performances réelles dépendent de la taille de la requête et de la dispersion en mémoire. Pour chaque échec d’accès au cache L1, une requête est transmise au cache L2, ce qui affecte considérablement les performances. Un échec d’accès au cache L1 peut coûter plus de 50 cycles d’horloge, et un échec d’accès au cache L2 coûtera plus de 200 cycles d’horloge vers la DRAM et plus de 75 cycles vers l’ESRAM.

Ces valeurs sont mesurées, mais optimistes. Pour voir les latences réelles, utilisez l’onglet ALU de Dr. PIX ou les différents compteurs de colonnes disponibles.

Une optimisation très importante consiste à utiliser les modes de tiling appropriés pour les textures et les tampons, en fonction du modèle d’accès. Les pixel shaders sont toujours traités par quads 2×2 ; les modes de tiling 2D sont donc très importants pour la vitesse du fetch de textures, car les texels voisins sont stockés à proximité en mémoire par rapport à la ligne de cache, ce qui réduit le nombre d’échecs d’accès au cache. L’utilisation d’une texture linéaire avec un pixel shader peut être jusqu’à 50 % plus lente que la lecture d’une texture en tiling. Les compute shaders qui utilisent des textures en entrée ou en sortie offrent les meilleures performances lorsque la taille du groupe de threads est un multiple de la ligne de cache, par exemple un multiple de 8×2 pour les formats 32 bpp. Lorsque des tampons sont utilisés, l’accès linéaire offre une vitesse maximale, et le matériel prend en charge les modes d’adressage AOS/SOA pour les tampons afin de réduire les échecs d’accès au cache lors de l’accès aux tampons. En décembre 2013, la XBOX One n’expose pas le paramètre de swizzling AOS/SOA pour les tampons. Le tableau suivant présente la répartition des performances dans ce module :

Opération	≤ 32 bpp	64 bpp	128 bpp	Commentaire
Lectures d’image bilinéaires	16 texels/cycle	8 texels/cycle	4 texels/cycle	4 pixels/adresses * quads 2×2
Lectures et écritures à échantillonnage ponctuel	4 texels/cycle	4 texels/cycle	4 texels/cycle	4 adresses, tout format
Gather4	16 texels/cycle	16 texels/cycle	16 texels/cycle	4 pixels/adresses * 2×2, n’importe quel composant unique
Lectures et écritures de tampon	16 éléments/cycle	N/A	N/A	4 adresses * 1x4 ≤ 32 bpp. La lecture/l’écriture de 2 ou 4 éléments réduit le débit à 4 éléments/cycle
Opérations atomiques sur tampon	16 opérations atomiques/cycle	8 opérations atomiques/cycle	N/A	Les opérations atomiques Cmpswap/avec retour réduisent le débit de moitié
Opérations atomiques sur image	4 opérations atomiques/cycle	4 opérations atomiques/cycle	N/A	Les opérations atomiques Cmpswap/avec retour réduisent le débit de moitié

Concernant les lectures et écritures de tampon ci-dessus : les chargements et stockages à 4 canaux ont le même débit que les chargements et stockages fusionnés à 1 canal. En effet, 1 DWORD par thread de shader en 4 cycles représente la même quantité de données par cycle que 4 DWORD par thread de shader en 16 cycles.

Dr. PIX fournit une analyse approfondie des performances du TCP et du TCC dans la section Caches.

Étape 4 : Le TD retourne les données au SP

Une fois que le TCP dispose des données, celles-ci sont transmises au bloc TD afin d’être retournées au shader. Le TD effectue le filtrage et la conversion de format, y compris la suppression du gamma (de-gamma). Le filtrage est ignoré pour les formats entiers (par exemple, R32_UINT) et les fetchs de tampon. Dans la plupart des cas, le TD peut filtrer quatre pixels à quatre canaux par cycle et retourner jusqu’à 16 DWORD par cycle au shader. En général, l’un ou l’autre de ces aspects constitue un goulot d’étranglement dans ce bloc, et il est possible de déterminer lequel en fonction du type de fetch ou du format. Plutôt que de présenter un grand tableau de formats et de vitesses, un programmeur graphique expérimenté n’a besoin de retenir que les points suivants :

Le TD dispose de quatre filtres à virgule fixe de 12 bits, qu’il peut chaîner pour prendre en charge la mantisse de 23 bits du FP32 ou la valeur 16 bits d’un U16.
Le TD dispose de trois canaux de 9 bits qui traitent l’exposant à virgule flottante.
Le filtrage trilinéaire/anisotrope réduit le débit, car les échantillons doivent être mélangés.

Pour appliquer ces règles, partez du plein débit. Si la mantisse FP ou la valeur entière nécessite plus de 12 bits, réduisez le débit de moitié. S’il y a plus de trois canaux à virgule flottante, réduisez à nouveau le débit de moitié. Pour le filtrage trilinéaire, réduisez encore le débit de moitié. Pour l’anisotropie avec un facteur N, divisez encore le débit par N. Vous obtenez ainsi le diviseur de débit dans le TD. Voici quelques exemples d’application de ces règles à de simples fetchs bilinéaires :

Les formats à virgule fixe de 8, 10 ou 11 bits par canal passent à plein débit, en utilisant une voie de filtre de 12 bits par canal.
Les formats à virgule fixe de 16 bits doivent utiliser deux voies de 12 bits par canal ; ainsi, s’il y a quatre canaux de 16 bits, le filtrage s’effectue à mi-débit. S’il y a deux canaux de 16 bits, il s’effectue à plein débit.
Le format FP32 à canal unique est à pleine vitesse. FP32x2 est à mi-vitesse et FP32x4 à quart de vitesse. Ce ralentissement s’explique par le fait qu’un canal FP32 occupe deux voies de 12 bits.
Le FP16 à canal unique est à pleine vitesse, tout comme FP16x2, mais FP16x4 est à mi-vitesse, car seuls trois canaux à virgule flottante peuvent être filtrés simultanément.
R11G11B10_FLOAT est à pleine vitesse, car la mantisse est inférieure à 12 bits et trois canaux à virgule flottante doivent être filtrés.

Si vous utilisez .x ou .xyz en HLSL sur une texture FP16x4, le débit reste de moitié, car le GPU filtre tous les canaux de la texture source avant de déterminer quels canaux retourner au shader.

Opérations atomiques

Les opérations atomiques sont des opérations mémoire qui effectuent une lecture-modification-écriture sur la destination en une seule transaction ininterrompue. Le GPU XBOX One dispose de trois types distincts d’opérations atomiques : les opérations atomiques LDS, les opérations atomiques GDS et les opérations atomiques mémoire. Seules les opérations atomiques mémoire sont abordées dans cette rubrique. Un shader peut demander une valeur de retour à une instruction atomique ; on parle alors d’opérations atomiques avec retour, ou simplement d’opérations atomiques à retour. Les instructions qui ne demandent pas de valeur de retour sont appelées opérations atomiques sans retour. La prise en charge matérielle des opérations atomiques est un sur-ensemble des opérations atomiques HLSL. Le type de données des opérations atomiques est constitué d’entiers 32 et 64 bits, signés ou non signés. Les opérations atomiques CMPSWAP, MIN et MAX sont également prises en charge sur les valeurs à virgule flottante 32 et 64 bits. Les opérations atomiques 64 bits ne sont prises en charge qu’avec les instructions de tampon ; sinon, la prise en charge des opérations atomiques sur image et sur tampon est symétrique. Chaque instruction atomique peut être avec retour, signalée par l’indicateur GLC=1 dans l’assembleur de shader, ou sans retour. HLSL DX11 n’expose qu’un sous-ensemble des opérations atomiques disponibles dans le matériel ; il manque notamment la prise en charge des opérations atomiques sur entiers 64 bits pour les tampons. L’absence de prise en charge des opérations atomiques MIN et MAX pour les valeurs à virgule flottante dans HLSL peut être contournée pour les valeurs à virgule flottante positives en utilisant les opérations atomiques MIN/MAX classiques sur entiers signés avec des valeurs asint(fp32). En effet, les valeurs à virgule flottante IEE754 de même signe sont ordonnées. L’opération atomique CMPSWAP devrait également fonctionner sur des valeurs asint(fp32). Le TCP (cache L1) a connaissance des opérations atomiques, mais n’effectue pas lui-même les opérations atomiques réelles. Il les combine d’abord en écriture, puis les transmet au TCC (cache L2) pour exécution. Le TCC (cache L2) est propre à chaque GPU ; il s’agit d’un cache à réécriture (writeback) de 512 Ko, associatif à 16 voies, avec 12 blocs de 8 Ko par banque et quatre banques. Voici les performances maximales du TCC :

4 lectures par cycle
3 écritures par cycle
3 opérations atomiques sans retour par cycle
1 opération atomique avec retour par cycle

En pratique, sur le GPU XBOX One, les opérations atomiques avec retour atteignent toujours environ deux tiers de la vitesse des opérations atomiques sans retour, et les opérations atomiques sans contention sont aussi rapides que les écritures classiques. En cas de forte contention sur les adresses de destination des opérations atomiques, la vitesse peut chuter à 1/20 - 1/6 de la vitesse d’écriture.

Annexe A : Vitesses de fetch de texture

Ces valeurs théoriques correspondent raisonnablement aux valeurs mesurées pour différents fetchs de texture.

Filtre	Format	Pic théorique, nombre de fetchs par cycle sur l’ensemble du GPU	Latence dans le shader, cycles (en supposant un coût complet, c.-à-d. sans optimisations anisotropes)
Ponctuel	BC1_UNORM	48	16
Bilinéaire	BC1_UNORM	48	16
Trilinéaire	BC1_UNORM	24	32
Aniso 2x	BC1_UNORM	12	64
Aniso 4x	BC1_UNORM	6	128
Ponctuel	R8_UNORM	48	16
Bilinéaire	R8_UNORM	48	16
Trilinéaire	R8_UNORM	24	32
Aniso 2x	R8_UNORM	12	64
Aniso 4x	R8_UNORM	6	128
Ponctuel	R8G8_UNORM	48	16
Bilinéaire	R8G8_UNORM	48	16
Trilinéaire	R8G8_UNORM	24	32
Aniso 2x	R8G8_UNORM	12	64
Aniso 4x	R8G8_UNORM	6	128
Ponctuel	R8G8B8A8_UNORM	48	16
Bilinéaire	R8G8B8A8_UNORM	48	16
Trilinéaire	R8G8B8A8_UNORM	24	32
Aniso 2x	R8G8B8A8_UNORM	12	64
Aniso 4x	R8G8B8A8_UNORM	6	128
Ponctuel	R8G8B8A8_UNORM_SRGB	48	16
Bilinéaire	R8G8B8A8_UNORM_SRGB	48	16
Trilinéaire	R8G8B8A8_UNORM_SRGB	24	32
Aniso 2x	R8G8B8A8_UNORM_SRGB	12	64
Aniso 4x	R8G8B8A8_UNORM_SRGB	6	128
Ponctuel	R10G10B10A2_UNORM	48	16
Bilinéaire	R10G10B10A2_UNORM	48	16
Trilinéaire	R10G10B10A2_UNORM	24	32
Aniso 2x	R10G10B10A2_UNORM	12	64
Aniso 4x	R10G10B10A2_UNORM	6	128
Ponctuel	R10G10B10_6E4_A2_FLOAT	48	16
Bilinéaire	R10G10B10_6E4_A2_FLOAT	48	16
Trilinéaire	R10G10B10_6E4_A2_FLOAT	24	32
Aniso 2x	R10G10B10_6E4_A2_FLOAT	12	64
Aniso 4x	R10G10B10_6E4_A2_FLOAT	6	128
Ponctuel	R10G10B10_7E3_A2_FLOAT	48	16
Bilinéaire	R10G10B10_7E3_A2_FLOAT	48	16
Trilinéaire	R10G10B10_7E3_A2_FLOAT	24	32
Aniso 2x	R10G10B10_7E3_A2_FLOAT	12	64
Aniso 4x	R10G10B10_7E3_A2_FLOAT	6	128
Ponctuel	R11G11B10_FLOAT	48	16
Bilinéaire	R11G11B10_FLOAT	48	16
Trilinéaire	R11G11B10_FLOAT	24	32
Aniso 2x	R11G11B10_FLOAT	12	64
Aniso 4x	R11G11B10_FLOAT	6	128
Ponctuel	R16G16_UNORM	48	16
Bilinéaire	R16G16_UNORM	48	16
Trilinéaire	R16G16_UNORM	24	32
Aniso 2x	R16G16_UNORM	12	64
Aniso 4x	R16G16_UNORM	6	128
Ponctuel	R16G16_FLOAT	48	16
Bilinéaire	R16G16_FLOAT	48	16
Trilinéaire	R16G16_FLOAT	24	32
Aniso 2x	R16G16_FLOAT	12	64
Aniso 4x	R16G16_FLOAT	6	128
Ponctuel	R32_UINT	48	16
Ponctuel	R32_FLOAT	48	16
Bilinéaire	R32_FLOAT	48	16
Trilinéaire	R32_FLOAT	24	32
Aniso 2x	R32_FLOAT	12	64
Aniso 4x	R32_FLOAT	6	128
Ponctuel	R16G16B16A16_UNORM	48	16
Bilinéaire	R16G16B16A16_UNORM	24	32
Trilinéaire	R16G16B16A16_UNORM	12	64
Aniso 2x	R16G16B16A16_UNORM	6	128
Aniso 4x	R16G16B16A16_UNORM	3	256
Ponctuel	R16G16B16A16_FLOAT	48	16
Bilinéaire	R16G16B16A16_FLOAT	24	32
Trilinéaire	R16G16B16A16_FLOAT	12	64
Aniso 2x	R16G16B16A16_FLOAT	6	128
Aniso 4x	R16G16B16A16_FLOAT	3	256
Ponctuel	R32G32_UINT	48	16
Ponctuel	R32G32_FLOAT	48	16
Bilinéaire	R32G32_FLOAT	24	32
Trilinéaire	R32G32_FLOAT	12	64
Aniso 2x	R32G32_FLOAT	6	128
Aniso 4x	R32G32_FLOAT	3	256
Ponctuel	R32G32B32A32_UINT	48	16
Ponctuel	R32G32B32A32_FLOAT	48	16
Bilinéaire	R32G32B32A32_FLOAT	12	64
Trilinéaire	R32G32B32A32_FLOAT	6	128
Aniso 2x	R32G32B32A32_FLOAT	3	256
Aniso 4x	R32G32B32A32_FLOAT	1.5	512

Annexe B : Vue d’ensemble d’un shader utilisant une instruction d’image

L’exemple suivant montre une instruction de mémoire vectorielle dans un binaire de shader :

  s_mov_b64        s[12:13], exec 
  s_wqm_b64        exec, exec
  s_mov_b32        m0, s4
  s_load_dwordx8   s[4:11], s[2:3], 0x00
  s_load_dwordx4   s[0:3], s[2:3], 0x08
  v_interp_p1_f32  v2, v0, attr1.x
  v_interp_p1_f32  v3, v0, attr1.y
  v_interp_p2_f32  v2, v1, attr1.x
  v_interp_p2_f32  v3, v1, attr1.y
  s_waitcnt        lgkmcnt(0)
  image_sample     v[2:5], v[2:5], s[4:11], s[0:3] dmask:0xf  

Voici une explication plus détaillée, ligne par ligne.

  s_mov_b64     s[12:13], exec

Exec est un registre architectural de 64 bits qui stocke le masque de bits d’exécution du wavefront actuel. Si un bit vaut 1 dans ce masque, les résultats d’exécution du thread sont enregistrés ; s’il vaut 0, ils sont ignorés. Les quads de moins de 4 pixels entraînent des 0 dans le masque pour certains threads dans les pixel shaders, de même que les wavefronts de moins de 64 sommets dans les vertex shaders. Ici, nous enregistrons le masque dans les SGPR 12 et 13.

  s_wqm_b64     exec, exec

Nous définissons le masque exec pour activer le mode quads entiers (whole quads mode). Il active tous les threads de tous les quads, et tous les threads de tous les quads seront désormais exécutés. Le compilateur doit le faire, car nous sommes sur le point d’effectuer une lecture de texture basée sur des gradients, qui nécessite les valeurs de tous les threads d’un quad 2×2.

  s_mov_b32     m0, s4

Nous sommes sur le point de lire des valeurs interpolées depuis le LDS ; nous devons donc configurer un registre de descripteur mémoire. Le GPU lui-même précharge le SGPR 4 avec les paramètres LDS appropriés pour ce wavefront de pixel shader.

  s_load_dwordx8  s[4:11], s[2:3], 0x00
  s_load_dwordx4  s[0:3],  s[2:3], 0x08
  s_waitcnt       lgkmcnt(0)  

Les instructions de mémoire vectorielle doivent avoir au moins un paramètre décrivant la texture ou un tampon. Dans le cas des instructions d’image, un descripteur d’échantillonneur est également requis. Ces instructions de chargement scalaire chargent un objet Texture Descriptor de 4 DWORD dans les SGPR 0, 1, 2, 3 et un objet Sampler Descriptor de 8 DWORD dans les SGPR 4, 5, 6, 7, 8, 9, 10 et 11. Le pilote graphique XBOX One transmet l’adresse du bloc mémoire stockant les descripteurs de shader dans les SGPR 2 et 3.

  v_interp_p1_f32  v2, v0, attr1.x
  v_interp_p1_f32  v3, v0, attr1.y
  v_interp_p2_f32  v2, v1, attr1.x
  v_interp_p2_f32  v3, v1, attr1.y  

Ces quatre instructions interpolent les coordonnées UV de la texture que nous sommes sur le point de lire. Chaque interpolant linéaire nécessite deux instructions. Alors que les descripteurs d’objets sont partagés entre tous les threads du wavefront et sont donc stockés dans des SGPR, les coordonnées UV, ou les décalages de texture ou de tampon, sont propres à chaque thread de shader ; ils doivent donc utiliser des VGPR.

  image_sample  v[2:5], v[2:5], s[4:11], s[0:3] dmask:0xf

Cette instruction émet une lecture de texture avec les coordonnées UV dans v[2:3] (les v[4:5] sont inutilisés mais requis ici), l’objet descripteur de texture dans s[0:3] et un objet descripteur d’échantillonneur dans s[4:11].

Références

Vue d’ensemble du GPU XBOX One Unités de calcul du GPU XBOX One

Introduction

Onboarding & Access

Setup & Install

Build Your First Title

Glossaire

Instructions de tampon et instructions d’image

Aide-mémoire : tableau récapitulatif des performances

Masquage de la latence

Vue d’ensemble matérielle d’une unité de texture

Le cycle de vie d’une instruction de mémoire vectorielle

Étape 1 : Émission de l’instruction

Étape 2 : Calcul des adresses et demande des données

Étape 3 : Le TCP charge les données et les transmet au TD

Étape 4 : Le TD retourne les données au SP

Opérations atomiques

Annexe A : Vitesses de fetch de texture

Annexe B : Vue d’ensemble d’un shader utilisant une instruction d’image

Références

​Glossaire

​Instructions de tampon et instructions d’image

​Aide-mémoire : tableau récapitulatif des performances

​Masquage de la latence

​Vue d’ensemble matérielle d’une unité de texture

​Le cycle de vie d’une instruction de mémoire vectorielle

​Étape 1 : Émission de l’instruction

​Étape 2 : Calcul des adresses et demande des données

​Étape 3 : Le TCP charge les données et les transmet au TD

​Étape 4 : Le TD retourne les données au SP

​Opérations atomiques

​Annexe A : Vitesses de fetch de texture

​Annexe B : Vue d’ensemble d’un shader utilisant une instruction d’image

​Références

Glossaire

Instructions de tampon et instructions d’image

Aide-mémoire : tableau récapitulatif des performances

Masquage de la latence

Vue d’ensemble matérielle d’une unité de texture

Le cycle de vie d’une instruction de mémoire vectorielle

Étape 1 : Émission de l’instruction

Étape 2 : Calcul des adresses et demande des données

Étape 3 : Le TCP charge les données et les transmet au TD

Étape 4 : Le TD retourne les données au SP

Opérations atomiques

Annexe A : Vitesses de fetch de texture

Annexe B : Vue d’ensemble d’un shader utilisant une instruction d’image

Références