Caches et cohérence sur le GPU XBOX One

• Introduction
• Aperçu des étapes du pipeline
• Présentation des caches
• Synthèse
• Conclusion

​

Introduction

​

Synchronisation du GPU

• Comment garantir que deux appels de dessin ou dispatchs ne s’exécutent pas simultanément. Cela est nécessaire pour garantir que l’appel de dessin qui produit les données n’exécute pas de vagues en même temps que celui qui consomme les données.
• Où insérer les différents événements programmables, c’est-à-dire en haut du pipeline ou en bas.

​

Aperçu des étapes du pipeline

• Lecture des données du tampon de commandes.
• Déclenchement des transferts DMA du tampon d’index pour le VGT.
• Lecture des paramètres du tampon indirect.
• Lecture des informations de prédication.
• Communication et synchronisation avec le ME.

1. Un paquet de dessin ou un paquet de commande de dispatch entre dans le processeur de commandes par le processeur de prélecture.
2. Le paquet est exécuté par le micro-moteur.
3. Les étapes de shader du paquet sont exécutées par l’entrée du processeur de shaders (SPI) et le séquenceur (SQ).
4. Le back-end de rendu à fonction fixe (comprenant le bloc d’exportation des shaders [SX], le bloc de profondeur [DB] et le bloc de couleur [CB]) termine le travail non lié aux shaders.

​

Événements de fin de pipe et de fin de shader

Figure 1. Pipeline de synchronisation avec des flèches indiquant à quel moment les événements EOS et EOP sont signalés

​

Barrière de pipeline

Figure 2. Si les wavefronts ou le travail back-end du producteur chevauchent les wavefronts du consommateur, une barrière est nécessaire pour garantir qu’ils se synchronisent correctement.

Vidage partiel

Fences EOS et EOP

​

Différences entre les barrières PARTIAL_FLUSH, fence EOS et fence EOP

Figure 3. Même si le producteur a terminé au moment où le consommateur commence et que les deux appels de dessin intermédiaires sont indépendants, le vidage partiel introduit un blocage. Dans ce cas, le blocage est inutile ; le producteur ne chevaucherait jamais le consommateur.

Figure 4. En utilisant des fences, il est possible de réduire ou d’éliminer le blocage du pipeline entre le producteur et le consommateur, à condition que les dessins intermédiaires soient indépendants.

DrawA (Producer)
WriteValueEndOfPipe( myFence, 1, D3D11X_WRITE_VALUE_END_OF_PIPE_EOS ); // Assuming the value is 0 in the fence location
Draw X N
InsertWaitOnMemory ( myFence, 0, EQUAL, 1, 0xffffffff );  

​

Présentation des caches

​

Opérations de cache prises en charge

• Les caches L2 et L1 prennent en charge le vidage et l’invalidation en une seule opération. Les caches L1 et L2 prennent également en charge une opération de réécriture sans invalidation, mais uniquement pour les lignes de cache spécialement marquées comme « volatiles ». Les lignes de cache volatiles doivent être marquées spécifiquement au moyen d’un descripteur de ressource et, en octobre 2014, elles ne sont pas prises en charge par le pilote graphique XBOX One. Les caches L1 et L2 ne respectent pas les plages de vidage.
• Les caches CB et DB prennent tous deux en charge le vidage et l’invalidation en une seule opération. Le CB ne respecte pas les plages de vidage.
• Seul le DB prend en charge une opération de vidage et d’invalidation par plage sur ses caches. Les autres blocs invalident toujours l’intégralité du cache. Cela signifie que le coût d’un vidage de cache peut être important.

​

Ressources D3D et caches

• Toutes les lectures et écritures de tampons non constants, de textures et d’UAV sont effectuées via les caches L1 et L2, respectivement le TCP et le TCC. En d’autres termes, toutes les instructions VMEM passent par les caches L1 et L2, qui sont des caches en lecture et en écriture.
• Les lectures de tampons scalaires sont effectuées via le K$et le cache L2. Le K$ est un cache en lecture seule qui lit via le L2. Toutes les instructions SMEM lisent via le K$ et le cache L2.
• Les instructions de shader sont lues via le I$et le cache L2. Le I$ est un cache en lecture seule.
• L’accès à la mémoire du tampon de couleur s’effectue via un ensemble de caches CB (bloc de couleur). Cela inclut la lecture des données pour le blending ; le blending lui-même a lieu dans l’unité CB. Les caches CB incluent les pixels réels et les métadonnées de surface, telles que CMask et FMask.
• L’accès à la mémoire du tampon de profondeur s’effectue via les caches du bloc de profondeur (DB). Cela inclut les données en lecture et en écriture pour les tests de profondeur, la compression et les mises à jour Hi-Z. Les caches DB incluent les pixels de profondeur réels, les métadonnées de la surface de profondeur telles que la compression (PMask et plans) et les informations Hi-Z (HTile).

​

Vidages en haut de pipe et en fin de pipe

​

Stratégies du cache L1

​

Synchronisation de surface

  FlushGpuCacheRange(D3D11_FLUSH_ENSURE_CB0_COHERENCY | D3D11_FLUSH_TEXTURE_L2_INVALIDATE | D3D11_FLUSH_COLOR_BLOCK_INVALIDATE, renderTarget0Base, renderTarget0Size );  

​

Synthèse

1. Identifiez les blocs qui seront responsables de la production et de la consommation des données. Producteurs typiques :
   1. CB : surfaces de couleur, pixels et métadonnées.
   2. DB : surfaces de profondeur, pixels et métadonnées.
   3. TCP/TCC : UAV en écriture directe, CopyMemoryToMemory.
   4. SO : stream-out (une synchronisation complète est nécessaire).
   5. CP : WriteValueEndOfPipe, WriteTimestampToMemory.
   6. CP DMA (peut utiliser le TCC) : WriteGDS, certaines CopyResources.
   7. CPU : écritures sur le CPU.

   [!NOTE] Pour plus d’informations sur l’amélioration des performances du rendu CPU, reportez-vous au livre blanc intitulé « Command Lists, Draw Bundles, and Deferred Contexts », disponible en téléchargement sur la page Livres blancs de XGD. Consommateurs typiques : 1. TCP/TCC : toutes les textures, tous les tampons de sommets et toutes les lectures d’UAV.

   1. K$/TCC : tous les tampons constants.
   2. CB : blending des couleurs.
   3. DB : test de profondeur.
   4. CP/PFP : tampons de prédication, indices de sommets et tampons indirects.
   5. CPDMA (peut éventuellement lire via le TCC) : ReadGDS depuis la mémoire, certaines CopyResources.
2. Insérez un vidage de cache pipeliné (en fin de pipe) pour le producteur.
   1. GpuSendPipelinedEvent pour CB, DB et SO.
   2. WriteValueEndOfPipe avec les indicateurs L1/L2 pour le TCP/TCC.
3. Utilisez la barrière de pipeline appropriée entre le producteur et le consommateur.
   1. Vidage partiel
   2. Fence EOS
   3. Fence EOP
   4. Synchronisation de surface
4. Après l’opération d’attente de la barrière, insérez une invalidation de cache en haut de pipe pour le consommateur. Cela se fait invariablement via une opération GpuCacheFlushRange, qui invoque une synchronisation de surface.

Figure 5. L’ordre du pipeline va de haut en bas. Les blocs bleus sont les blocs fonctionnels du GPU. Les blocs verts sont les opérations qu’ils effectuent.

​

Exemples

1. Si le CPU utilise de la mémoire à écriture combinée et que l’adresse du tampon dynamique n’a pas été vue dans cette image, ne faites rien. Si les pointeurs ne sont pas alignés sur 64 octets et que l’allocation est séquentielle, videz le cache K.
2. Émettez un vidage GPU en haut de pipe des caches K et L2. Comme les vidages ne respectent pas la plage, n’émettez un vidage qu’une seule fois par lancement.

1. Émettez un appel de dessin producteur qui effectue le rendu dans l’objet X en tant que cible de rendu via CB0.
2. Émettez un vidage et une invalidation pipelinés des pixels du tampon de couleur. Méthode 1. À utiliser lorsqu’il existe davantage de dessins ou de dispatchs indépendants entre les producteurs et les consommateurs, afin de tenter d’éliminer une bulle.
   1. Émettez une écriture mémoire EOS PS_DONE.
   2. Avant que le consommateur ne démarre, insérez une attente sur la mémoire.

1. Insérez un PS_PARTIAL_FLUSH.
2. Insérez un vidage du cache L2 en haut de pipe.
3. Émettez un dessin consommateur.

1. Émettez un dispatch producteur qui écrit dans l’UAV X.
2. Émettez un vidage pipeliné des caches L1/L2.
3. Émettez une écriture de fence EOP F (nécessite une synchronisation entre un CS et un PS).
4. Avant que le consommateur ne démarre, insérez une attente sur la fence F. (Vous pouvez également utiliser un CS_PARTIAL_FLUSH à la place des étapes 3 et 4.)
5. Émettez un vidage et une invalidation pipelinés des caches CB et CB_META.
6. Émettez un dessin.

1. Émettez un dispatch producteur qui écrit dans l’UAV X.
2. Émettez un vidage pipeliné des caches L1/L2.
3. Émettez une écriture de fence EOP F (nécessite une synchronisation entre un CS et un PS). Méthode 1 Avant que le consommateur ne démarre, insérez une attente sur la mémoire F sur le PFP. La synchronisation doit avoir lieu au niveau du PFP, car c’est lui qui lit les tampons indirects. Méthode 2 Utilisez une attente sur la mémoire sur le ME, suivie de PFP_SYNC_TO_ME.
4. Émettez un dessin indirect.

​

Conclusion