Configuration
Vous pouvez configurer une trace en ouvrant le panneau Options à partir de la barre d’outils en haut de la vue. Vous pouvez y sélectionner les Global IDs à tracer, parmi diverses autres options. Une fois la trace configurée, cliquez sur le bouton « Generate Trace » de la barre d’outils pour générer la trace. Les vagues d’un Shader Engine et les instructions d’un SIMD peuvent être capturées dans une même trace. Vous pouvez configurer le SIMD à tracer dans le panneau Options.Vagues et instructions
Une fois la trace générée, vous voyez les vagues exécutées sur le SIMD tracé. Pour afficher toutes les vagues exécutées sur le Shader Engine sélectionné, activez « All Waves » dans le panneau Options. Lorsque vous affichez les vagues du SIMD tracé, la vue s’ajuste automatiquement au nombre de vagues affichées. Pour figer les vagues afin qu’elles ne se déplacent pas lors du redimensionnement de la vue, activez « Fixed Lane Count » dans le panneau Options. Lorsque vous cliquez sur une vague du SIMD tracé, la vue bascule pour afficher cette vague et ses instructions. Les panneaux Trace Tokens et Shader Stats deviennent visibles. Le panneau Trace Tokens affiche les jetons capturés par le matériel pendant l’exécution de la vague, avec une entrée par instruction exécutée. Si « Other SIMD » est activé dans le panneau Options, il inclut aussi les jetons du SIMD qui partage une unité de texture avec le SIMD tracé, ce qui aide à comprendre l’utilisation des ressources partagées. Le panneau Shader Stats affiche les statistiques de chaque instruction dans l’ordre où elle apparaît dans le binaire du nuanceur. Vous pouvez basculer cette vue entre la vague sélectionnée et toutes les vagues du nuanceur sélectionné sur le SIMD tracé.Statistiques du nuanceur (Shader Stats)
Les statistiques du nuanceur représentent soit la vague sélectionnée, soit toutes les vagues du nuanceur sélectionné sur le SIMD tracé, selon l’option de bascule.- Issue Count : nombre moyen de fois où l’instruction a été émise.
- Arbitration Stall Count : nombre moyen de blocages d’arbitrage subis par l’instruction.
- Arbitration Stall Cost : nombre moyen de SCLK pendant lesquels les vagues étaient prêtes mais n’ont pas pu émettre l’instruction. Pour plus de détails, consultez la section sur les blocages ci-dessous.
- Total Stall Cost : nombre moyen de SCLK entre cette émission et l’émission précédente sur la même vague.
- Issue Gap : nombre moyen de SCLK entre l’instruction et l’instruction précédente sur la même vague.
- Issue Cost : nombre moyen de SCLK nécessaires pour émettre l’instruction.
- % of Total : coût de l’instruction par rapport au coût de toutes les instructions. Coût total = intervalle d’émission + coût de blocage + coût d’émission
- % of Longest : coût de l’instruction par rapport à l’instruction la plus coûteuse.
- % Visited : pourcentage de vagues ayant émis l’instruction au moins une fois.
Rendu
Les traces comportant de nombreuses instructions peuvent peser sur les performances de rendu de la chronologie. Si cela pose problème, vous pouvez utiliser le seuil « Instructions » du panneau Options pour configurer la granularité de la plage de temps à partir de laquelle les instructions sont dessinées.Comprendre l’utilisation
Des lignes de chronologie supplémentaires peuvent être ajoutées à partir du panneau Options : « Utilization » et « Perf Counters ». Les lignes d’utilisation affichent l’utilisation des unités fonctionnelles parallèles du matériel : VMEM (texture et LDS), VALU, scalaire (SALU et SMEM) et branchement/message. Il existe aussi des lignes supplémentaires pour l’export et l’inactivité. Chaque unité peut émettre une instruction à la fois. Les instructions immédiates, indiquées par le jeton IMMED, font exception : elles sont traitées en interne par chaque vague sans utiliser d’ALU ni de chemin d’exécution. Chaque vague peut les exécuter simultanément. Des lignes d’utilisation supplémentaires sont aussi dérivées des données d’instructions pour afficher des informations utiles, comme les blocages d’export et les blocages d’arbitrage. Les compteurs de performances capturent l’activité de quelques-uns des principaux bus du Shader Engine. Ils peuvent aider à obtenir une vue d’ensemble des performances et à identifier les goulots d’étranglement, comme la vitesse de création des vagues par le SPI ou l’utilisation du bus d’export. Le compteur représente le nombre de cycles pendant lesquels le bus a été actif au cours de la période d’échantillonnage.Vue d’ensemble de l’architecture
L’architecture des nuanceurs de la XBOX Series X|S repose sur des Work Group Processors (WGP), qui exécutent des programmes de nuanceurs sur un ensemble d’éléments de travail. Un WGP se compose de 4 SIMD32, de deux chemins de mémoire de texture et d’une mémoire de nuanceur (LDS). Les SIMD32 sont les ALU vectorielles avec leurs GPR vectoriels. Chaque WGP contient aussi un cache scalaire (SQC) qui comprend à la fois le cache d’instructions et le cache de données scalaires.ALU scalaire et vectorielle
Les ALU scalaire et vectorielle sont similaires en ce sens qu’elles émettent une instruction qu’elles placent dans une file FIFO. L’instruction rassemble ensuite ses opérandes en lisant des GPR ou en récupérant les résultats d’instructions précédentes. Lorsque tous les opérandes sont disponibles, l’instruction peut s’exécuter. En raison de la concurrence avec d’autres instructions pour la lecture des GPR, ce délai entre l’émission et l’exécution est variable. Pour tracer la latence d’exécution, activez « Exec Latency » dans le panneau Options. Cette option nécessite une nouvelle trace pour collecter les données. Lorsque vous sélectionnez une vague, le panneau Trace Tokens affiche la latence d’exécution de chaque instruction. L’ALU vectorielle dispose de deux pipelines d’exécution parallèles : FMA normal et transcendantal. Une seule instruction est émise par cycle d’horloge, mais les deux pipes peuvent s’exécuter simultanément. Le pipe transcendantal ne peut accepter une nouvelle instruction qu’une fois tous les 4 cycles d’horloge au maximum.Mémoire de texture et LDS
Les deux SIMD32 d’une paire sélectionnent chacun des vagues pour émettre une instruction VMEM (texture ou LDS) et envoient cette instruction à un arbitre central. Cet arbitre choisit entre les deux SIMD, ainsi qu’entre LDS et texture. Cela introduit une incertitude quant au moment où l’instruction est réellement envoyée à l’unité d’exécution (Texture Addresser ou LDS). Pour tracer la latence d’exécution, activez « Exec Latency » dans le panneau Options. Cette option nécessite une nouvelle trace pour collecter les données. Lorsque vous sélectionnez une vague, le panneau Trace Tokens affiche la latence d’exécution de chaque instruction. Cela fournit une vue complète de l’activité sur le bus VMEM partagé. Les instructions de chacun des 4 types sont conservées dans l’ordre : Simd0 LDS, SIMD0 TA, SIMD1 LDS, SIMD1 TA.LDS-Direct et interpolation vectorielle
Les instructions VALU qui utilisent LDS-Direct (y compris les instructions VINTERP) sont retardées par l’arbitre d’instructions pendant environ 5 cycles avant d’être émises. Ce délai est visible dans la trace. Après qu’une vague a émis une instruction LDS_direct/vinterp, il s’écoule environ 5 cycles avant que cette vague puisse émettre une instruction VALU de type normal. D’autres vagues peuvent émettre des opérations VALU pendant ce temps.Exports et allocation SX
L’export désigne le processus de transfert des données des VGPR vers le SX (tampon d’export). Pour les nuanceurs de pixels, il concerne les données de couleur et de profondeur; pour les nuanceurs de vertex, les données de position et de paramètres. Ce chemin est aussi utilisé pour envoyer des données au GDS. Avant de pouvoir effectuer un export, un nuanceur de pixels ou de vertex doit se voir allouer de l’espace dans le tampon du SX. Si une vague tente d’émettre une instruction d’export avant d’avoir reçu une allocation, elle se met en veille jusqu’à ce que l’allocation ait lieu. Contrairement aux architectures précédentes, il n’y a pas d’« allocation anticipée » (où l’allocation avait lieu au démarrage de la vague). Toutes les allocations ont lieu pendant l’exécution de la vague. Contrairement aux autres instructions, les exports se déroulent en deux temps et sont signalés séparément dans la trace du nuanceur. L’émission de l’instruction correspond en réalité à une demande d’export, et non à l’export lui-même. Cela est indiqué dans la trace par un jeton EXPREQ_GFX ou EXPREQ_GDS. Tous les exports de nuanceurs PS et VS utilisent le type GFX pour leurs exports normaux, et GDS a son propre type. Une demande d’export peut porter sur plusieurs DWORD par thread. Un peu plus tard, la demande d’export est accordée, et c’est à ce moment que les données sont réellement lues dans les VGPR et transférées vers le tampon de sortie. Cela est indiqué dans la trace par un jeton EXPGNT_PAR_COL ou EXPGNT_POS_GDS. Pour les nuanceurs de pixels, EXPGNT_PAR_COL indique un export de couleur ou de profondeur, et EXPGNT_POS_GDS un export GDS. Pour les nuanceurs de vertex, EXPGNT_PAR_COL indique un export de paramètres, et EXPGNT_POS_GDS un export de position ou une opération GDS.Branchements
Les branchements sont indiqués par le jeton BRANCH_TAKEN. BRANCH_NOT_TAKEN indique que le branchement n’a pas été pris lors de cette exécution particulière de l’instruction. La même instruction de branchement peut apparaître de nombreuses fois dans la trace si elle a été exécutée dans une boucle. Elle peut être tantôt BRANCH_TAKEN, tantôt BRANCH_NOT_TAKEN.Blocages
Blocage d’export
Lorsqu’une vague attend d’émettre une instruction d’export, on parle de blocage d’export. Il s’agit du temps écoulé entre l’émission de l’instruction précédente et l’émission de la demande d’export. Les blocages d’export sont visualisés par étape de nuanceur dans les lignes Utilization. Les exports peuvent être bloqués en attendant de l’espace dans le tampon d’export. Vous pouvez voir à quel moment une vague dispose d’espace alloué dans le tampon d’export en recherchant le jeton EXPORT_ALLOC dans le panneau Trace Tokens.Blocage d’arbitrage
Pour chaque vague prête à émettre, l’arbitre choisit une vague pour émettre une instruction de chaque type : VMEM (texture et LDS), VALU, scalaire (SALU et SMEM) et branchement/message. Ces types correspondent aux lignes d’utilisation de la vue Shader Trace, auxquelles s’ajoute une ligne pour les exports. Il est possible que, pour un type d’instruction donné, l’arbitre ne choisisse aucune vague. Cela peut se produire si l’exécution est saturée et occupée par des instructions précédentes. Si une vague est prête à émettre une instruction mais n’est pas choisie par l’arbitre, elle est bloquée. Le jeton READY est inséré au premier SCLK où la vague était prête mais ne s’est pas exécutée. Tous les SCLK entre ce moment et la prochaine instruction émise par la vague sont considérés comme un blocage. Une vague n’est pas prête si elle n’a aucune instruction valide, si elle attend la levée d’un blocage de dépendance, si elle attend la fin d’une instruction multicycle ou si elle attend sur s_waitcnt, s_sleep ou s_nop. Si une vague est prête, elle dispose d’une instruction valide et peut soit remporter l’arbitrage (ce qu’indique une instruction émise), soit le perdre (une autre vague l’a remporté ou aucune vague ne l’a remporté). Une vague peut perdre l’arbitrage si la file FIFO de l’unité réceptrice est pleine (SIMD, TA, LDS, RAM des demandes d’export), si l’arbitre est verrouillé dans une clause où seule cette vague peut gagner, ou si l’arbitre attend l’émission d’une instruction mémoire multicycle (recherchez une instruction précédente). Les blocages d’arbitrage sont visualisés par catégorie d’instruction dans les lignes Utilization. L’Arbitration Stall Cost de chaque instruction est visible dans le panneau Shader Stats. Il s’agit d’un sous-ensemble du Total Stall Cost de l’instruction.Émission d’instructions multicycles
Certaines instructions prennent un temps variable à être émises. Le nombre de SCLK nécessaires pour émettre chaque instruction est indiqué dans la colonne « Issue » du panneau Trace Tokens. La largeur d’une instruction sur la chronologie dépend aussi du nombre de SCLK nécessaires pour l’émettre.Schémas courants
« Cascade » VALU
