Meilleures pratiques pour le lancer de rayons sur XBOX Series X|S

Cette rubrique décrit les meilleures pratiques pour le lancer de rayons sur XBOX Series X|S. Le lancer de rayons est une technique de rendu viable sur XBOX Series X|S depuis plus d’un an, et nous avons beaucoup appris sur la façon d’obtenir des performances maximales avec le matériel XBOX. Cette rubrique résume les éléments importants que nous avons appris et fournit des conseils, des astuces et des meilleures pratiques pour développer des jeux de haute qualité utilisant le lancer de rayons sur XBOX Series X|S.

​

Lancer de rayons sur XBOX Series X|S

Nous avons constaté une excellente adoption de la fonctionnalité de lancer de rayons sur les consoles XBOX Series. Aujourd’hui, plus de 20 titres sont commercialisés avec la prise en charge du lancer de rayons sur XBOX Series X. Plusieurs de ces titres ont ensuite pris en charge le lancer de rayons sur XBOX Series S. Les effets simples comme les ombres et l’occlusion ambiante sont courants, et certains titres ont également implémenté des réflexions et l’illumination globale. Lors du Xfest 2019, le GDK de novembre 2019 venait d’être publié et aucun titre n’utilisait le lancer de rayons. À la fin de 2020, seulement trois titres fonctionnaient avec le GDK d’août 2020. Depuis, plusieurs améliorations ont été apportées au runtime. Nous comprenons maintenant beaucoup mieux ce qu’il faut pour obtenir de bonnes performances de lancer de rayons sur nos consoles.

​

Générateur de BVH à l’exécution

Le générateur de BVH (hiérarchie de volumes englobants) à l’exécution s’exécute sur le GPU; il consomme donc du temps GPU qui serait autrement utilisé pour la rastérisation ou le lancer de rayons. À ce jour, tous les titres utilisent le générateur de BVH à l’exécution pour générer leur structure d’accélération de niveau supérieur (TLAS). Ils effectuent des regénérations complètes à chaque image; n’essayez donc pas de mettre à jour une TLAS. Pour les structures d’accélération de niveau inférieur (BLAS), environ la moitié des titres utilisent encore le générateur de BVH à l’exécution pour la géométrie statique. L’autre moitié utilise le générateur de BVH hors ligne. Pour la géométrie dynamique, tous les titres continuent d’utiliser le générateur de BVH à l’exécution, car c’est la seule option. Les performances de génération du générateur de BVH à l’exécution sont excellentes dès le départ. Il a été comparé aux GPU NVIDIA et AMD sur PC et offre d’excellentes performances. Les développeurs ont indiqué qu’ils voulaient une API de génération explicitement par lots, dans laquelle plusieurs structures d’accélération sont générées simultanément pour de meilleures performances GPU. Selon les commentaires des développeurs, les performances ont été multipliées par au moins 10, voire 20. Pour comprendre d’où viennent ces gains de vitesse, il est important de comprendre le fonctionnement du générateur de BVH à l’exécution. La génération d’une BVH n’est pas une seule répartition, ni même deux. Il s’agit d’une série de nombreuses répartitions, toutes exécutées l’une après l’autre avec des barrières de vue d’accès non ordonné (UAV) entre elles. En fournissant toutes vos générations de niveau inférieur dans un seul appel d’API, celles-ci peuvent être planifiées plus efficacement et réduire le nombre de barrières UAV dans cette phase. Figure 1. Diapositive 8. Depuis le Xfest 2019, nous avons modifié le fonctionnement du parcours. Les quads constituent la base de la façon dont les BLAS stockent la géométrie. Lors du Xfest précédent, le triangle 2 (Tri2) et le triangle 3 (Tri3) du nœud AMD étaient encore utilisés et étaient fournis dans le matériel, comme le montre la figure 1. Certaines métadonnées auxiliaires étaient stockées dans la BVH et chargées explicitement pendant le parcours. En renonçant à l’utilisation de Tri2 et Tri3, le sommet 4 peut désormais stocker les métadonnées de géométrie. Maintenant, lorsqu’il faut accéder à ces données, elles ont plus de chances de se trouver dans le cache, ce qui donne de meilleures performances. Il s’agissait principalement d’une optimisation des performances, mais elle s’est faite au prix de BLAS légèrement plus grandes en mémoire que si Tri2 et Tr3 avaient été utilisés. Le générateur à l’exécution forme des quads à partir de paires de triangles adjacents dans la liste. Le premier thread vérifie si le premier et le deuxième triangle forment un quad, le deuxième thread vérifie le troisième et le quatrième triangle, le troisième thread vérifie le cinquième et le sixième triangle, et ainsi de suite. Chaque thread vérifie si les triangles _N_ et _N_+1 peuvent former un quad et donc utiliser Tri0 et Tri1 dans un nœud feuille. Figure 2. Diapositive 10. Dans le diagramme de gauche de la figure 2, les deux triangles ne partagent pas d’arête; ils ne forment donc pas un quad. Au milieu, il y a deux triangles qui forment un quad. Ils se rapprochent d’un rectangle et constituent un quad approprié. Du côté droit, les deux triangles forment un quad. Cependant, le gonflement de l’AABB englobante est trop important. Ce quad serait rejeté et il y aurait plutôt un seul triangle dans chaque nœud. La tolérance de gonflement autorisée de la boîte est contrôlée par le seuil de formation des quads. Plus le seuil est élevé, plus la tentative de former des quads à partir de ces deux triangles est agressive. Cela produit des BVH plus petites, car il y a moins de nœuds de triangles, mais au prix d’un parcours moins performant. À l’inverse, si vous définissez un seuil bas, vous ne formerez des quads qu’à partir de deux triangles s’ils se rapprochent de la forme d’un rectangle ou d’un quad, ce qui produit des BVH plus grandes, mais peut améliorer les performances du parcours. L’utilisation du calcul asynchrone pour générer vos BVH n’est pas obligatoire, mais elle procure un gain de performances important. Bon nombre de ces générations, en particulier celles de niveau supérieur, n’utilisent pas toute la largeur du GPU, surtout sur XBOX Series X avec ses 26 WGP/52 CU. En exécutant l’API de génération par lots et le calcul asynchrone, vous pouvez masquer efficacement le coût de la majeure partie de la génération de vos BVH. Dans le cas d’un titre, les développeurs ont généré une TLAS de 1,5 milliseconde presque gratuitement en la déplaçant vers le calcul asynchrone. S’il est possible de commencer à générer des structures d’accélération bien avant qu’elles soient nécessaires dans l’image, elles pourraient être d’excellentes candidates pour le calcul asynchrone. Les générations de niveau supérieur et de niveau inférieur comportent une série d’indicateurs que vous connaissez si vous avez travaillé sur PC. Dans la génération, ces indicateurs contrôlent deux systèmes différents. Le premier est le degré d’utilisation des AABB FP16 dans les BVH. Le second est la mesure dans laquelle le processus appelé reconstruction de treelets est effectué sur la BVH. Ces deux éléments sont configurables à l’aide de l’API par lots BuildRaytracingAccelerationStructureBatched2X. Il est important de comprendre que le GPU AMD RDNA 2 prend en charge les AABB FP16 et les AABB FP32. Il ne s’agit pas d’une décision tout ou rien. La génération produit des BVH comportant à la fois des AABB FP16 et FP32 dans une seule BVH. Les AABB FP16 font la moitié de la taille des AABB FP32, ce qui améliore les taux de réussite du cache. Elles doivent être gonflées de façon conservatrice pour garantir qu’elles contiennent toute la géométrie. La quantification de FP32 vers FP16 agrandit ces boîtes, selon les valeurs. Ce comportement est configurable à l’aide du membre de seuil de gonflement des boîtes FP16 et de l’API FP16BoxInflationThreshold. Plus ce seuil est bas, plus les boîtes FP32 sont utilisées. Ces BVH utilisent alors plus de mémoire. Cependant, les limites plus serrées donnent des performances de parcours plus rapides. À l’inverse, si vous définissez un seuil élevé, davantage d’AABB FP16 sont utilisées, moins de mémoire est utilisée, les limites sont plus lâches et les performances de parcours sont moindres.

​

Reconstruction de treelets

Le générateur à l’exécution utilise une BVH linéaire (LBVH). Elle est facile à paralléliser et constitue une bonne candidate pour une implémentation sur le GPU. Sous sa forme brute, la qualité d’une LBVH peut être médiocre. Pour améliorer la qualité de ces BVH, un processus de reconstruction de treelets est exécuté par la suite. Pour plus de détails, consultez Fast Parallel Construction of High-Quality Bounding Volume Hierarchies. Ce processus permute des sous-arbres de la BVH pour améliorer l’heuristique de surface. Cela améliore à son tour les performances du parcours.

​

Remontée dans la structure d’accélération de niveau supérieur (TAPU)

Une autre option du générateur de BVH à l’exécution, en ce qui concerne la TLAS, est la remontée dans la structure d’accélération de niveau supérieur (TAPU, Top-level Acceleration structure Pull Up). Dans la TLAS, les limites des instances sont grandes et se chevauchent. Les caméras se trouvent souvent à l’intérieur des instances, de sorte que les origines des rayons se trouvent à l’intérieur des limites des instances. Par conséquent, il devient difficile pour le code de parcours de suivre le meilleur chemin dans la BVH lors du parcours. Le matériel teste le rayon contre quatre boîtes simultanément et retourne ces quatre intersections triées par distance. Si les rayons se trouvent à l’intérieur des quatre boîtes, la distance jusqu’à l’intersection est nulle dans tous les cas. L’ordre retourné est inconnu, mais vous avez besoin de limites d’instance qui épousent étroitement la géométrie. C’est là que l’optimisation TAPU s’applique et améliore la situation. Figure 3. Diapositive 17. La figure 3 montre une structure composée d’une série de feux de circulation montés sur un poteau vertical suspendu à un poteau horizontal. Du côté gauche, les boîtes bleues en pointillés sont les limites d’instance. Toute cette structure est une BLAS et correspond aux limites d’instance. Il y a de l’espace vide en bas, par lequel les rayons peuvent passer. Du côté droit, il n’y en a pas. Figure 4. Diapositive 18. Dans la figure 4, l’instance du haut est englobée dans une seule boîte. Celle-ci se trouve au premier niveau de la BLAS. Vous pouvez aussi descendre de deux niveaux et examiner les 16 premières boîtes, comme le montre l’illustration du bas. Ces boîtes sont extraites, puis remontées dans la TLAS, d’où le nom TAPU. Cela signifie que les rayons qui passent sous le feu de circulation, et qui auraient auparavant croisé les limites de l’instance, ne le font plus. Tout code qui aurait été exécuté lors de cette transition de la TLAS vers la BLAS n’a plus à l’être.

​

Générateur de BVH hors ligne

Le générateur de BVH hors ligne n’était pas disponible au lancement de la XBOX Series X|S, mais il a été ajouté en 2020. Si vous avez commercialisé vos titres sur PC, vous avez utilisé l’API standard pour générer les BVH. Le format de la BVH est entièrement opaque pour vous en tant que développeur. Il n’existe aucun moyen de générer vos BVH hors ligne, de les placer sur un disque optique ou dans votre téléchargement numérique, puis de faire télécharger des BVH prégénérées par les clients. Il existe une API sur PC qui vous permet de générer une BVH à l’exécution, de la mettre en cache sur un disque dur, puis de la recharger. Comme la vitesse du disque dur peut être faible et que ces BVH peuvent être invalidées par des mises à jour de pilotes, l’intérêt de cette approche est assez faible. Comme les consoles XBOX Series sont des plateformes fixes et disposent d’un stockage SSD haute vitesse, nous pouvons générer nos BVH hors ligne, puis les distribuer sur le SSD. De la même façon que nous pouvons distribuer des textures pré-swizzlées pour XBOX Series X|S, nous pouvons aussi prégénérer nos BVH. Le GDK de mai 2020 a ajouté la prise en charge du générateur de BVH hors ligne. Il s’agit d’un processus qui s’exécute sur le processeur, et non sur le GPU. Le processus s’exécute sur un PC Windows plutôt que sur la console. Le générateur de BVH hors ligne est un générateur de classe mondiale construit sur la technologie de pointe Intel Embree. Nous travaillons avec cette technologie et pouvons convertir une BVH générée par Intel Embree en une BVH prête pour le matériel XBOX Series X|S. Aucun traitement supplémentaire n’est effectué à l’exécution pour utiliser cette BVH une fois qu’elle a été chargée. Actuellement, il n’est utilisé que pour les BLAS. Aucun développeur n’a encore demandé à générer une TLAS hors ligne. Ce type de génération présente peu d’intérêt. Lorsque nous avons initialement publié le générateur de BVH hors ligne en mai 2020, nous ne prenions pas en charge les générations avec BUILD_FLAG_ALLOW_UPDATE. Cela signifiait que tout ce qui était animé par squelette, comme les personnages, les arbres et l’herbe, ne pouvait pas être généré hors ligne, car il n’y avait aucun moyen de les réajuster à l’exécution. Cet indicateur a été ajouté au GDK d’avril 2021 à la suite de vos commentaires. Le générateur de BVH hors ligne convient désormais à tout contenu non procédural. Par exemple, une géométrie dont vous connaissez déjà l’apparence hors ligne. Cet indicateur peut ne pas convenir si un joueur peut modeler ou sculpter du nouveau contenu, car le développeur ne saura pas à quoi il ressemblera hors ligne. C’est maintenant le seul cas où le générateur de BVH hors ligne ne convient pas. Utilisez cette option, car elle ne consomme pas votre budget d’image GPU de la même façon que le générateur de BVH à l’exécution. Le générateur de BVH hors ligne vous fait non seulement gagner du temps GPU, mais il produit aussi des BVH de bien meilleure qualité que le générateur de BVH à l’exécution. Le générateur de BVH hors ligne génère également des paires de quads quasi parfaites. Contrairement au générateur de BVH à l’exécution, où un seul thread analysait deux triangles adjacents, le générateur de BVH hors ligne effectue une recherche complète. Si le triangle 7 doit être jumelé au triangle 12 pour former le meilleur quad, c’est ce qu’il fait. De plus, aucune mémoire de travail n’est requise pour les générateurs de BVH hors ligne. Vous pouvez simplement les charger à partir du disque. Vous n’avez pas besoin d’allouer de mémoire de travail supplémentaire sur la console à l’exécution pour la génération. Le générateur de BVH hors ligne ne consomme qu’une partie de votre budget d’image GPU. À l’exécution, appelez CopyRaytracingAccelerationStructure avec le nouvel indicateur D3D12_RAYTRACING_ACCELERATION_STRUCTURE_COPY_MODE_DESERIALIZE. La désérialisation, qui n’est qu’un memcpy, se produit sur la chronologie du GPU. Elle est beaucoup plus rapide qu’une véritable génération. À l’avenir, si vous trouvez ce coût prohibitif, un processus de désérialisation sur le processeur pourrait être ajouté. Il consiste à supprimer certains en-têtes et à apporter quelques modifications. Si vous le souhaitez, faites-le-nous savoir. Le générateur de BVH hors ligne produit des BVH de meilleure qualité que le générateur de BVH à l’exécution grâce à la division des triangles. Les BVH comprennent souvent des triangles de forme irrégulière orientés selon des angles inhabituels. Nous pouvons améliorer les performances en ajoutant des AABB supplémentaires autour de certains triangles. Cela réduit l’heuristique de surface pour obtenir un parcours plus rapide. Cela augmente la consommation de mémoire. Tenez-en compte lorsque vous décidez du degré d’agressivité avec lequel vous voulez appliquer cette optimisation. Figure 5. Diapositive 26. Pour expliquer ce qu’est la division des triangles et son fonctionnement, le triangle du côté gauche de la figure 5 est qualifié de triangle normal. Si un rayon traverse la boîte rouge en pointillés, il y a environ 50 % de chances que ce rayon touche le triangle. À l’inverse, du côté droit de la figure 5, un autre triangle occupe la même AABB. Cependant, il n’y a qu’environ 5 % de chances qu’un rayon touche ce triangle. Figure 6. Diapositive 27. Dans la figure 6, au milieu, nous avons une division unique. Plutôt que de délimiter le triangle dans une seule AABB, on le délimite dans deux AABB sans rien modifier à la géométrie du triangle. Si un rayon traverse la même boîte rouge en pointillés, il y a environ 40 % de chances qu’il la traverse sans aucun test de triangle. On peut améliorer la situation en divisant à nouveau le triangle, jusqu’à avoir deux divisions et délimiter le triangle avec trois boîtes. Plus on ajoute de boîtes, plus il y a de chances que le rayon traverse la boîte rouge en pointillés sans avoir à considérer ce triangle comme candidat. Figure 7. Diapositive 28. Si davantage de divisions est préférable, on pourrait avoir un nombre infini de divisions qui se rapprochent de la forme de ce triangle avec un nombre infini d’AABB. À terme, la surface du triangle de la figure 7 serait proche de la surface du triangle lui-même. Elle n’aurait pas été artificiellement gonflée par l’AABB qui le contient. Bien que davantage de divisions soit préférable, les AABB utilisent de la mémoire et leur consommation augmente considérablement. Les tests rayon/AABB ont aussi leurs coûts. Si un nombre infini de boîtes délimite chaque triangle, vous devrez effectuer un nombre infini de tests rayon/AABB. Or, le matériel ne peut effectuer qu’un nombre limité de ces tests. Lorsqu’Intel Embree applique cette optimisation, il n’effectue cette division que là où elle est nécessaire. S’il rencontre un triangle normal, il ne le divisera pas, car ce n’est pas nécessaire. Intel Embree détermine si le triangle long et mince, positionné hors axe, est candidat à trois, quatre, cinq divisions ou plus. Vous pouvez utiliser TriangleSplitFactor pour contrôler le nombre de divisions du triangle et la quantité de mémoire supplémentaire utilisée. Les BVH de la XBOX Series X|S occupent environ 120 à 140 octets par triangle. C’est vrai pour la BVH hors ligne et pour les BVH générées à l’exécution après compactage. L’augmentation du facteur de division des triangles à des valeurs plus élevées augmente la taille de la BVH de 10 à 20 % supplémentaires. Malheureusement, ces deux chiffres sont trois fois plus élevés que la BVH NVIDIA sur PC. Cependant, on ne peut pas faire grand-chose à ce sujet pour cette génération de consoles, car le matériel XBOX Series X|S est une plateforme fixe avec une disposition mémoire fixe requise par l’instruction d’intersection. Si vous avez un grand jeu comportant un milliard de triangles uniques dans un monde ouvert, vous pourriez avoir environ 140 Go de BVH hors ligne. La compression traditionnelle pourrait vous donner une réduction de deux pour un, mais pour distribuer votre jeu, vous auriez encore 70 Go, soit un disque Blu-ray (BD) supplémentaire entier. Pour résoudre ce problème de compression, vous pouvez utiliser la compression des BVH.

​

Compression des BVH

Les développeurs nous ont demandé de revoir la taille de nos BVH. Nous avons livré une solution de compression dans le GDK de mars 2022. La compression des BVH réduit de quatre à six fois la taille des BVH sur le disque. Le milliard de triangles que vous souhaitez distribuer dans votre titre en monde ouvert ne nécessite désormais que 25 Go au lieu de 140 Go. Avant que le GPU puisse accéder aux triangles, les BVH compressées doivent être décompressées. Ce processus fait intervenir le processeur. La compression des BVH n’économise pas de mémoire sur la console à l’exécution; elle vous permet de distribuer des jeux plus petits avec des tailles d’installation plus petites. Une étape de compression sur le processeur est effectuée hors ligne sur une machine de génération, sur un PC Windows, une fois la BVH hors ligne générée. Une étape de décompression sur le processeur est effectuée sur la console à l’exécution pour la rendre prête pour le GPU. Si vous utilisez le pilote PC XBOX Series X|S sur un PC Windows, un nouvel indicateur D3D12XBOX_RAYTRACING_ACCELERATION_STRUCTURE_COPY_MODE_SERIALIZE_AND_COMPRESS a été ajouté à l’API CopyRaytracingAccelerationStructure, qui demande la sérialisation et la compression en une seule étape. Pour la décompression à l’exécution sur la console, utilisez la bibliothèque XG et la nouvelle fonction XGBVHComputer::DecompressBVH. Vous utilisez peut-être déjà cette bibliothèque pour les textures. Actuellement, la décompression à l’exécution se fait uniquement sur le processeur, et elle est monothread, car les développeurs ne veulent généralement pas que nous fassions notre propre multithreading. En supposant un taux de compression moyen de 5:1, 250 à 360 Mo d’entrée par seconde lus à partir du SSD produisent 1,2 à 1,8 Go de sortie par seconde. Comme le SSD peut lire des données jusqu’à 2 Go par seconde, un seul thread ne suffira pas à atteindre le débit de décompression requis. Si la décompression des BVH sur le processeur devient un goulot d’étranglement pour votre chargement, envisagez d’utiliser davantage de threads. Vous pouvez facilement décompresser des BVH sur 1, 2, 3 ou 4 threads simultanément pour accélérer vos temps de chargement.

​

DXR 1.0 + extensions

Sur XBOX Series X|S, DXR 1.0 (DirectX Raytracing) conforme au PC est pris en charge tel qu’il était lors de sa publication il y a plusieurs années. La seule omission importante est l’API des nuanceurs pouvant être appelés (Callable shaders). Peu de développeurs ont demandé cette API. DXR 1.0 est souvent utilisé par les développeurs qui ont déjà créé des titres utilisant le lancer de rayons sur PC Windows, où le lancer de rayons fonctionne déjà, et qui veulent maintenant qu’il fonctionne aussi sur XBOX Series X|S. Bien que ce n’était pas le cas au lancement de la XBOX Series X|S, de nombreux développeurs ont indiqué que cette option fonctionnait dès le départ. Ils ont appuyé sur F7, puis sur F5. Le jeu s’est exécuté et ils avaient le lancer de rayons. Bien que l’exécution d’un titre DXR 1.0 sur les consoles XBOX Series fonctionne (et ce, depuis un certain temps), ce n’est pas la voie vers des performances optimales. Si vous voulez distribuer DXR 1.0 avec votre titre, vous devrez peut-être consacrer plus de temps à l’optimiser pour XBOX Series X|S. Les extensions présentées à la figure 8 facilitent cette tâche. Figure 8. Diapositive 39. Ces extensions sont regroupées en plusieurs catégories. Pour interroger la longueur du rayon une fois TraceRay terminé, utilisez :

• XDXR_RayTCurrent()
• XDXR_RayTMin()

Pour retourner les positions des sommets du triangle touché, pour une intersection validée ou en attente, utilisez :

• XDXR_GetHitTriangleVertexPositions()
• XDXR_GetCommittedHitTriangleVertexPositions()
• XDXR_GetPendingHitTriangleVertexPositions()

Pour obtenir le pointeur du nœud d’instance/feuille touché par le rayon, utilisez :

• XDXR_GetPendingBlasLeafNodePtr()
• XDXR_GetPendingInstanceNodePtr()
• XDXR_GetCommittedBlasLeafNodePtr()
• XDXR_GetCommittedInstanceNodePtr()

Pour appeler immédiatement le nuanceur d’intersection la plus proche (closest-hit) sur le triangle/l’instance, utilisez :

• XDXR_SetShortCircuitIntersectNodes()

Dans DXR 1.0 sur XBOX, diverses informations sont retournées une fois l’appel TraceRay terminé. Vous n’avez pas besoin d’utiliser un nuanceur d’échec (miss shader) ou un nuanceur d’intersection la plus proche pour replacer ces informations dans la charge utile du rayon. Pour des effets comme les ombres ou l’occlusion ambiante, vous devez savoir s’il y a eu une intersection. Vous n’avez pas besoin de connaître les informations de diffusion ni les coordonnées barycentriques. Tout ce dont vous avez besoin, c’est d’un oui ou d’un non binaire. Il est inutile d’exécuter un nuanceur d’échec ou un nuanceur d’intersection la plus proche et d’avoir une charge utile de 4 octets pour déterminer ce qui ne serait qu’un seul bit. Deux de ces extensions peuvent être appelées après TraceRay. Vous pouvez obtenir la longueur finale du rayon et la comparer à la longueur d’origine pour voir s’il y a eu une intersection. Vous pouvez aussi lire les trois positions de sommets de l’intersection validée. Plutôt que de lier le tampon de sommets qui contient les positions à l’appel DispatchRays, puis de lire à partir de votre propre structure de données, ces positions de sommets proviennent directement de la BVH. Cela peut vous faire économiser de la mémoire. Vous pouvez vous débarrasser de votre copie du tampon de sommets. Figure 9. Diapositive 41. L’exemple de code de la figure 9 montre l’utilisation des extensions XDXR_RayTCurrent et XDXR_GetCommittedHitTriangleVertexPositions. Commencez par initialiser maxT à la longueur maximale du rayon, puis appelez TraceRay. Comparez XDXR_RayTCurrent une fois l’appel TraceRay terminé et le retour au nuanceur de génération de rayons effectué. Si la valeur est inférieure à la valeur définie à l’origine, il y a eu une intersection. S’il y a eu une intersection et que vous voulez connaître les positions des sommets, appelez XDXR_GetCommittedHitTriangleVertexPositions. Vous obtenez les trois positions de sommets directement à partir de la mémoire de la BVH.

​

Lancer de rayons en ligne

Bien que certains titres utilisent encore DXR 1.0, nous recommandons aux développeurs d’utiliser DXR 1.1 et le lancer de rayons en ligne. DXR 1.1, qui existe sur PC, a introduit une version du lancer de rayons en ligne appelée RayQuery. Elle vous permet de lancer des rayons à partir d’étapes de nuanceur traditionnelles, comme les nuanceurs de calcul ou les nuanceurs de pixels. RayQuery ne peut pas appeler d’autres nuanceurs. Vous ne pouvez pas, par exemple, gérer une transparence par test alpha en appelant un nuanceur d’intersection. Tout doit être fait dans ce nuanceur, sans appel de fonction disponible. XBOX ne prend pas en charge l’API RayQuery de DXR 1.1. Cependant, il existe une autre option. DXR 1.0 reste une boîte noire sur console, comme sur PC. Le code source du générateur de BVH à l’exécution n’est pas fourni, et le code de parcours est caché dans le pilote derrière l’appel DispatchRays. Le code de parcours des rayons a été implémenté en HLSL (langage de nuanceur de haut niveau). Vous pouvez consulter ce code et l’inclure directement dans vos propres nuanceurs. Le code de parcours est fourni en HLSL dans un fichier d’en-tête livré avec le GDK. Vous pouvez l’inclure avec hash #include dans vos nuanceurs et l’utiliser comme vous le souhaitez. Vous appelez hash #include avec le fichier XDXRStandaloneTraverseShortStack.hlsli inclus dans le répertoire d’installation du GDK. Il peut être utilisé dans toute étape de nuanceur pouvant allouer de la mémoire LDS ou de la mémoire partagée de groupe. Aujourd’hui, il s’agit du nuanceur de calcul et du nuanceur de pixels. Comme la source est fournie, vous pouvez modifier le nuanceur. S’il y a une fonctionnalité dont vous n’avez pas besoin (ou dont vous payez le coût) et que vous voulez vous en débarrasser, supprimez le code. Si vous avez du code à ajouter à votre nuanceur parce que vous voulez personnaliser votre titre, ajoutez ce code directement à l’en-tête et continuez à l’inclure. Aucune exigence binaire n’impose que votre nuanceur corresponde à quoi que ce soit dans le pilote. Il n’est versionné d’aucune façon. Il est là pour que vous l’incluiez dans vos nuanceurs. IMPORTANT : Nous nous réservons le droit de modifier le format de la BVH à tout moment, avec n’importe quelle mise à jour du GDK. Ces nuanceurs peuvent changer d’un GDK à l’autre. Si vous apportez des modifications, préparez-vous à fusionner vos modifications personnalisées à chaque mise à jour du GDK. Figure 10. Diapositive 46. L’interface de l’en-tête autonome de la figure 10 est semblable à RayQuery de DXR 1.1. Elle s’appelle XboxRayQuery et accepte bon nombre des mêmes indicateurs et des mêmes entrées. En fait, elle se ressemble beaucoup, et c’est pourquoi nous n’avons pas investi de temps dans DXR 1.1. Si vous utilisez l’approche du lancer de rayons en ligne, vous voudrez peut-être gérer le test alpha. Cela peut se faire de l’une des deux façons suivantes.

• La fonction Proceed retourne chaque fois qu’une intersection non opaque est trouvée et demande s’il faut valider cette intersection. Vous pouvez utiliser l’intrinsèque de candidat pour obtenir des informations sur les coordonnées barycentriques, effectuer une recherche de texture, puis vérifier le canal alpha pour déterminer si vous voulez accepter l’intersection.
• Injectez votre fonction d’intersection de test alpha directement dans la boucle de parcours. L’avantage en performances est que vous ne sortez pas de la boucle de parcours pour exécuter votre code, puis devoir y revenir au début. Exécutez votre fonction de test à l’intérieur de la boucle de parcours pour économiser des registres vectoriels à usage général (VGPR), augmenter l’occupation et exécuter moins d’instructions. Nous vous recommandons d’utiliser cette option en raison de ces avantages.

L’approche du lancer de rayons en ligne présente plusieurs avantages par rapport à DXR 1.0. Comme le compilateur voit l’ensemble du nuanceur, y compris le parcours, il peut éliminer le code de parcours inutilisé qui n’est pas pertinent pour votre titre. Par exemple, la gestion des primitives procédurales AABB. Les exigences en VGPR sont généralement inférieures d’environ 10 VGPR à celles de DXR 1.0. Cela vous donne une meilleure occupation et de meilleures performances. Elle peut être personnalisée selon les exigences de votre titre, ce qui en fait une meilleure option que DXR 1.0. Le lancer de rayons en ligne présente des inconvénients, certains plus importants que d’autres. Si vous devez gérer une variation importante des matériaux, il peut être difficile de le faire dans un seul nuanceur. Vous pourrez peut-être gérer un ou deux matériaux avec une instruction switch ou une instruction if. Cependant, lorsque vous devez appeler 1 000 fonctions différentes pour gérer 1 000 nuanceurs d’intersection la plus proche différents, ou du code pour gérer différents matériaux, cela pèse lourdement sur l’apparence du nuanceur et sa compilation. PIX ne reconnaît pas que vous effectuez du lancer de rayons. Il s’agit simplement d’un autre nuanceur de calcul qui appelle du code fourni dans un fichier d’en-tête. Comme il n’est pas reconnu comme du lancer de rayons, le profilage des performances et le débogage sont délicats. De plus, si vous avez une implémentation DXR 1.0 en cours d’exécution, il y a des étapes supplémentaires pour que cela fonctionne, en plus de la solution qui fonctionnait déjà.

​

Occupation

L’occupation est importante pour obtenir de bonnes performances avec le lancer de rayons. Une faible occupation est le problème de performances le plus courant dans les titres. Des développeurs ont implémenté le lancer de rayons, mais constatent de piètres performances. Les titres ont souvent des objets d’état du pipeline de lancer de rayons (RTPSO) qui utilisent plus de 160 VGPR. Cela correspond à une occupation de seulement six vagues lors d’une exécution en Wave32. Si le lancer de rayons était exécuté en Wave64, l’occupation serait de trois. C’est beaucoup trop faible. La meilleure pratique consiste pour un titre à atteindre une occupation élevée, avec 12 Wave32 ou plus exécutées simultanément. Figure 11. Diapositive 52. La figure 11 montre une boucle de parcours simple et réduite. Il s’agit d’une boucle while qui se lit ainsi : « tant qu’il reste des zones de la BVH à explorer, effectuer un test d’intersection de rayon ». La figure 11 montre l’intrinsèque _XB_BvhIntersectRay. La vague n’a plus rien à faire : elle attend la réponse à « qu’est-ce que ce rayon a touché, et à quelle distance? », puis elle se bloque. Il est essentiel que le GPU planifie une autre vague pour remplacer celle-ci. Si votre occupation est de un, vous n’avez d’autre choix que de bloquer tout le SIMD en attendant le retour de la demande d’intersection de cette vague. Plus l’occupation est élevée, plus le GPU dispose d’options pour planifier de nouvelles vagues. C’est pourquoi il est important d’avoir 12, 13, 14, 15 ou 16 vagues exécutées simultanément. Comme notre code de parcours utilise 2 Ko de LDS ou de mémoire partagée de groupe pour chaque Wave32, il est impossible de dépasser une occupation de 16. C’est la limite, même si le matériel peut atteindre une occupation de 20. Vous ne pouvez pas l’atteindre en raison de la quantité de LDS utilisée par le nuanceur. Comme l’occupation de 16 ne peut pas être dépassée, il est inutile d’essayer de réduire votre nombre de VGPR sous 64. Les RTPSO doivent être lancés en allouant autant de VGPR que les nuanceurs les plus coûteux de l’ensemble du RTPSO. Il n’y a aucune visibilité sur les nuanceurs que vous appelez; on suppose donc que n’importe lequel d’entre eux peut être appelé. Par conséquent, vous devez allouer les VGPR au niveau le plus élevé de tous ces nuanceurs. Les nuanceurs d’intersection quelconque (any-hit) utilisent leurs VGPR en plus de ceux utilisés par le parcours. N’enregistrez pas et ne restaurez pas les VGPR en mémoire chaque fois qu’un appel est fait au nuanceur d’intersection quelconque. Il est important de maintenir un faible nombre de VGPR dans les nuanceurs d’intersection quelconque. Les nuanceurs d’intersection la plus proche sont généralement ceux qui ont les exigences en VGPR les plus élevées. Ces nuanceurs se rapprochent d’un nuanceur de pixels d’une passe de rastérisation normale. Ils évaluent généralement les matériaux, l’éclairage, la BRDF, etc.; ils ont donc le nombre de VGPR le plus élevé. Gardez cela à l’esprit lorsque vous examinez le nombre de VGPR de l’ensemble du RTPSO. Nous vous recommandons de créer un RTPSO par usage. Cela signifie, par exemple, avoir un RTPSO pour les ombres, un RTPSO pour l’occlusion ambiante ou un RTPSO pour les réflexions. Par exemple, les ombres ont généralement des exigences en VGPR inférieures à celles des réflexions. Lorsque vous effectuez le rendu des ombres par lancer de rayons, vous pouvez obtenir une plus grande occupation pour les ombres que pour les réflexions. Si vous créiez un seul RTPSO pour les réflexions et les ombres, il serait plafonné aux exigences en VGPR des réflexions. Un RTPSO pour les ombres peut s’exécuter avec une occupation plus élevée et de meilleures performances. Il est essentiel de garder les nuanceurs d’intersection quelconque aussi simples que possible. Ils sont appelés en ligne avec le parcours. Chaque fois qu’un seul rayon évalue un nuanceur d’intersection quelconque, il retarde tous les autres threads qui n’ont pas besoin d’exécuter ce nuanceur. Il est recommandé de garder les nuanceurs aussi petits que possible. N’essayez pas d’y évaluer l’éclairage et de le stocker dans la charge utile. Effectuez le minimum de travail : décidez si vous voulez accepter l’intersection, puis revenez au parcours. DXR 1.0 alloue une pile de 32 Mo au moment de la création du périphérique pour prendre en charge l’enregistrement et la restauration des registres, ainsi que la récursion. Le conseil en 2019 était de ne pas utiliser la récursion. C’est toujours vrai aujourd’hui. C’est un problème de performances dont il est difficile de se sortir. Pour une allocation de pile de 32 Mo, le mot pile est légèrement surchargé. Il y a en fait deux piles. Il y a la pile que chaque vague a allouée dans la LDS pour suivre son chemin dans la BVH et le nœud auquel elle doit revenir. Et il y a la pile qui existe en mémoire globale et qui sert à enregistrer et à restaurer les registres. Pour le second type de pile, si une seule vague a beaucoup de registres à déverser et doit écrire beaucoup de registres en mémoire, les 32 Mo peuvent s’épuiser rapidement. Cette pile de 32 Mo peut agir comme une limite d’occupation dans les cas extrêmes. Depuis le GDK de mars 2022, 32 Mo sont alloués sur les consoles XBOX Series X et XBOX Series S. Dans le GDK de juin 2022, la XBOX Series S alloue une pile beaucoup plus petite, car elle compte moins de processeurs de groupe de travail que la XBOX Series X. Si vous n’utilisez pas cette pile, vous pouvez la désactiver au moment de la création du périphérique. Par exemple, si vous utilisez exclusivement DXR 1.1 et la voie du lancer de rayons en ligne, aucun registre ne serait déversé, à quelque fin que ce soit.

​

RTPSO hors ligne

XBOX peut toujours compiler des nuanceurs en DXBC ou en langage intermédiaire DirectX (DXIL), comme sur PC Windows. Mais en tant que plateforme fixe, XBOX peut aussi précompiler les nuanceurs jusqu’au microcode AMD, prêt à être exécuté sans compilation supplémentaire. Il n’y a aucune difficulté à le faire pour les nuanceurs de sommets, les nuanceurs de pixels et les nuanceurs de calcul si vous fournissez une signature racine. Les nuanceurs de calcul, de sommets et de pixels sont des éléments de code indépendants qui sont compilés et autonomes. Ils n’effectuent pas d’appels de fonction vers d’autre code. Il n’y a aucune ABI à gérer lors d’un autre appel. Ils sont faciles à compiler en microcode. Malheureusement, les nuanceurs de lancer de rayons sont beaucoup plus complexes. Ils ont des dépendances externes envers du code que le compilateur ne peut pas voir. Le code de parcours existe dans le pilote, mais pas dans le compilateur. Lorsque vous compilez un nuanceur de lancer de rayons, l’ensemble du nuanceur ne peut pas être compilé jusqu’au microcode AMD. La compilation ne va que jusqu’au DXIL. Lorsque vous compilez des nuanceurs DXR, utilisez la cible lib_6_3 (Library Shader Model 6.3). Ces nuanceurs sont compilés en DXIL. Cela fonctionne de la même façon que sur PC. Ce n’est que lorsque vous appelez CreateStateObject à l’exécution que le microcode AMD est produit. Dans certains cas, les RTPSO qui contiennent des centaines ou des milliers de nuanceurs peuvent prendre des secondes plutôt que des millisecondes. Un appel CreateStateObject de plusieurs secondes est à prévoir. Un temps de compilation de deux secondes peut être masqué derrière un écran de chargement. Si votre titre en monde ouvert permet aux joueurs de s’y déplacer à grande vitesse et que vous ne pouvez pas retarder de deux secondes l’affichage d’un objet pour compiler un nouveau RTPSO, cela posera problème. Comme XBOX ne prend pas actuellement en charge DXR 1.1, l’API AddToStateObject, qui ajoute des nuanceurs aux RTPSO, ne vous aidera pas. Vous pouvez plutôt précompiler entièrement les RTPSO hors ligne. C’est plus complexe que d’appeler DXC. À l’aide du pilote PC XBOX Series X|S, qui est le même pilote que celui que vous utiliseriez avec le générateur de BVH hors ligne, compilez vos RTPSO jusqu’au microcode AMD. Appelez CreateStateObject, qui est la même API que celle à appeler à l’exécution sur la console. Sérialisez le RTPSO sur le SSD à l’aide de l’API SerializeStateObjectX. Une fois écrit sur le SSD, ce blob ne fait que quelques Mo, selon le nombre de nuanceurs que vous avez. Vous pouvez charger ce bloc à partir du SSD à l’exécution et utiliser l’API DeserializeStateObjectX pour obtenir un RTPSO précompilé et chargeable sans étape de compilation. Ces bibliothèques DXIL peuvent être compilées en RTPSO de deux façons qui présentent une différence subtile. La première option est un RTPSO entièrement autonome. Il s’agit d’un RTPSO prêt à être lié au pipeline et utilisé dans un appel DispatchRays. La seconde option, que nous appelons un RTPSO, est aussi une collection. Il s’agit d’un groupe de nuanceurs qui ont soit un objectif commun, soit une relation commune avec un objet ou un niveau particulier. Ces nuanceurs peuvent être compilés sous forme d’un seul blob ou d’une seule entité, puis partagés entre plusieurs RTPSO à l’exécution. Avec cette option, vous pouvez créer un RTPSO à l’exécution à partir de plusieurs collections précompilées hors ligne. Plutôt que d’être compilées en microcode AMD à l’exécution, ces collections précompilées sont liées dans le pilote. Ce processus prend généralement environ 10 millisecondes. Cette étape de précompilation hors ligne supprime tout DXIL et toutes les métadonnées pour réduire la taille. Si vous effectuez une association de sous-objets à l’exécution, qui est une fonction de l’API DXR, ce n’est pas possible avec cette option. Avec la seconde option, vous obtenez les identificateurs de nuanceur à partir du RTPSO. Ils sont requis au début de chaque enregistrement de votre table de liaison des nuanceurs. Ce processus, ainsi que la compression des BVH, est illustré dans l’exemple ATG OfflineRT.

​

PIX

Beaucoup d’efforts ont été investis dans la prise en charge de DXR par PIX. Nous avons aussi travaillé sur l’Acceleration Structure Viewer et l’affichage des ressources dans la vue Pipeline. Deux domaines actuellement lacunaires, mais qui font l’objet de beaucoup de travail, sont les PDB de nuanceurs pour le lancer de rayons, qui ne sont pas pris en charge actuellement, et la possibilité de déboguer des rayons ou des threads dans les appels DispatchRays. Si vous avez des suggestions pour améliorer PIX ou la prise en charge de DXR, ou d’autres commentaires, sélectionnez le bouton Feedback dans le coin supérieur droit de PIX et faites-nous part de vos commentaires sur la prise en charge de DXR ou sur tout autre domaine que vous souhaitez porter à notre attention. Figure 12. Diapositive 65. Les images suivantes montrent à quoi ressemble l’Acceleration Structure Viewer. La figure 12 montre un appel de répartition. La sélection d’une structure d’accélération à gauche vous donne une caméra mobile qui peut tourner autour d’une vue globale de votre structure d’accélération. Vous pouvez voir les triangles individuels, les instances individuelles et les BLAS qui composent l’ensemble de votre TLAS. Figure 13. Diapositive 66. La figure 13 montre une carte thermique. Utilisez-la pour voir où se trouvent les points chauds de performances dans votre scène. Elle prend le nuanceur de lancer de rayons en ligne et le rend compatible avec le PC. Votre PC hôte exécute maintenant le code de parcours dans PIX. Comme il s’agit d’une version instrumentée, il est possible d’extraire des informations sur le nombre d’itérations de la boucle de parcours nécessaires pour ce rayon. Ces informations peuvent être visualisées à l’écran sous forme de couleurs. Figure 14. Diapositive 67. La figure 14 montre que les objets, comme cette poubelle mise en surbrillance à l’avant de la scène, peuvent être sélectionnés. Vous pouvez déterminer qu’elle n’est pas fusionnée au sol. Si elle l’était, cela créerait une grande limite d’instance. Il est important de sélectionner des objets et de voir où ils se trouvent dans la scène. Figure 15. Diapositive 68. Dans la figure 15, un arbre est sélectionné. L’Acceleration Structure Viewer affiche aussi toutes les autres copies de cet arbre. Cette figure compte environ 10 copies de l’arbre. En sélectionnant un arbre, les neuf autres sont mis en surbrillance. Cela montre que l’instanciation est utilisée et que 10 BLAS différentes ne sont pas utilisées pour ces arbres. Figure 16. Diapositive 69. La figure 16 montre la possibilité récemment ajoutée de visualiser les rayons directement dans l’Acceleration Structure Viewer. Comme il s’agit d’une version instrumentée d’un parcours, vous pouvez extraire les origines, les directions et les étendues des rayons. Ils peuvent être dessinés sous forme de lignes filaires directement dans la scène. Un seul rayon du côté gauche de l’écran de la figure 16 semble transpercer le bâtiment et ressortir de l’autre côté. Au départ, cela semblait être un bogue de PIX. Le bâtiment présente en fait une petite fissure très fine. Un rayon a traversé le bâtiment, puis est ressorti par l’arrière. L’élimination des faces arrière était désactivée. C’est ce type de visualisation qui, nous l’espérons, vous sera utile lorsque vous examinerez vos problèmes de performances.

​

Résumé

En résumé :

• Le lancer de rayons est possible sur les consoles XBOX Series X|S.
• Vous devez porter une attention particulière aux performances.
• Tenez compte des ressources artistiques au moment de leur création. Cela comprend les nuanceurs que vous écrivez, les indicateurs de génération que vous utilisez, le fait que vous utilisiez une API propre à XBOX ou le calcul asynchrone.
• La mémoire peut être une préoccupation importante. En particulier avec les consoles XBOX Series S, environ 500 Mo de mémoire sont nécessaires pour vos BLAS ou TLAS.

Tous ces aspects doivent être pris en compte dès le début lorsque vous développez le lancer de rayons pour votre titre. L’équipe PIX travaille fort pour améliorer PIX. Nous espérons que PIX fonctionnera de façon à ce que vous puissiez résoudre vous-même tous vos problèmes de lancer de rayons GPU, de débogage et de performances, sans avoir à communiquer d’abord avec l’ATG pour obtenir une aide particulière.

​

Étapes suivantes

Si vous souhaitez consulter les informations des documents de présentation liés à cette vue d’ensemble, téléchargez les fichiers suivants à partir de XBOX Developer Download Secure Data Storage (SDS).

• Jeu de diapositives : GR09_Best Practices for Raytracing on XBOX Series X|S.pptx dans Xfest 2022 Graphics Track PowerPoints (Xfest2022GfxPPTs.ZIP)
• Présentation vidéo : GR09.mp4 dans Xfest 2022 Graphics Track Videos (Xfest2022GfxVids.ZIP)

​

Télécharger les présentations Microsoft PowerPoint et les vidéos

1. Accédez à Téléchargements du Game Development Kit (GDK).
2. Sous Select file type, sélectionnez Conference Materials, puis sélectionnez Confirm.
3. Sous Select build/version number, choisissez l’une des présentations graphiques suivantes.
   • Xfest 2022 Graphics Track PowerPoints
   • Xfest 2022 Graphics Track Videos
4. Sélectionnez Download Now, puis attendez la fin du téléchargement du fichier .zip.
5. Accédez à votre dossier Téléchargements local, puis décompressez (extrayez) les fichiers du dossier compressé.

​

Voir aussi

Introduction au lancer de rayons