Générateur hors ligne
XDXR permet de générer des BVH hors ligne, de les compresser au besoin et de les charger à partir du disque à l’exécution. Cela peut produire des BVH de meilleure qualité pour de meilleures performances de traversée, et nécessite beaucoup moins de temps GPU que le générateur à l’exécution. Le générateur de BVH hors ligne ne prend actuellement en charge que la génération de BLAS, y compris les BLAS modifiables ainsi que les BLAS statiques. On s’attend à ce qu’un jeu typique génère la plupart de ses BLAS hors ligne, et n’effectue que les générations de TLAS et les mises à jour de BLAS pendant une image à l’exécution. Le générateur hors ligne peut effectuer un fractionnement des triangles pour éviter les coûts liés aux triangles longs, minces et inclinés, dont les volumes englobants peuvent être beaucoup plus grands que leur surface. De plus, il peut effectuer une meilleure « quadification » des triangles dans les nœuds feuilles; consultez la section « Quads » ci-dessous. Consultez l’exemple OfflineRT pour obtenir des informations sur la génération de BVH hors ligne, ainsi que sur la sérialisation, la désérialisation et la compression des BVH hors ligne. Consultez aussi la page Compression de BVH XDXR pour plus de détails. Notez que les BVH générés hors ligne ne sont valides que pour la version du GDK avec laquelle ils ont été générés. Les BVH devront être régénérés après une mise à jour de version du GDK.Générations par lots
XDXR prend en charge les générations de BVH « par lots ». La génération ou la mise à jour de plusieurs BVH en parallèle peut être de 10 à 25 fois plus rapide qu’en séquence. Consultez BuildRaytracingAccelerationStructureBatched2X. De plus, envisagez d’utiliser le calcul asynchrone pour superposer les générations de BVH à des charges de travail comme les ombres. Il pourrait être possible de compenser entièrement le coût de génération, ou d’activer des options de qualité de génération supplémentaires pour une traversée plus rapide.FP16
Le test d’intersection BVH de RDNA2 prend en charge deux types de nœuds AABB : des variantes à virgule flottante 32 bits et 16 bits. Les nœuds de boîte FP16 ne peuvent être utilisés que lorsque les étendues de l’AABB se situent dans la plage représentable en FP16. Pour offrir davantage d’occasions d’économiser de la mémoire, la géométrie peut être remise à l’échelle par des puissances de deux afin de tenir dans la plage FP16. Cette fonctionnalité peut être activée avecD3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_MINIMIZE_MEMORY. Bien que les boîtes FP16 soient plus petites, elles peuvent dégrader les performances de traversée, car la précision réduite fait gonfler les AABB. Une heuristique de gonflement des boîtes est utilisée pour déterminer quand le gonflement est acceptable. Pour remplacer l’heuristique par défaut, spécifiez D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS1:: FP16BoxInflationThreshold. Une valeur supérieure à 10.0f force tous les AABB à utiliser FP16 et réduit les allocations pessimistes de BVH. Une valeur inférieure à 1.0f force tous les AABB à utiliser FP32. On peut aussi obtenir ce résultat en spécifiant D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_TRACE sans D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_MINIMIZE_MEMORY.
TAPU
XDXR partage les mêmes pratiques exemplaires et les mêmes pièges en matière de performances que la plupart des autres générateurs de BVH à deux niveaux (TLAS + BLAS). Un sujet de préoccupation courant concerne les grands volumes englobants de BLAS remplis d’espace vide, ou qui croisent fortement d’autres instances de BLAS. Si deux instances ont des volumes englobants qui se croisent, il peut être impossible pour la traversée de déterminer la position d’intersection la plus proche sans traverser les deux instances. La situation est encore pire lorsque davantage d’instances se chevauchent, ou lorsque l’origine du rayon se trouve à l’intérieur des volumes englobants, auquel cas aucun tri ne peut être effectué. Parmi les objets particulièrement problématiques, on trouve par exemple les lignes électriques suspendues, qui ont probablement des volumes englobants très grands par rapport au volume du maillage d’origine et qui risquent de couvrir de grandes zones de la scène. Un autre exemple est la combinaison de plusieurs petits objets en une seule BLAS : les limites sont étendues pour contenir chaque maillage, mais il y aura probablement de grandes zones d’espace vide entre eux. Parfois, la solution la plus appropriée à ces problèmes consiste à fractionner ou à combiner des objets pendant les phases de création ou de modification du contenu. Cependant, cela peut être difficile, voire impossible, lorsqu’on ajoute des effets de lancer de rayons à des titres existants, ou plus tard dans le pipeline de création du jeu. Pour offrir un certain degré de contrôle à cet égard, XDXR implémente l’option « TAPU » (TLAS-Pull-Up) dans son générateur de BVH. Celle-ci permet à l’utilisateur de marquer des instances individuelles comme nécessitant une « remontée » dans la TLAS. En spécifiant l’indicateurD3D12XBOX_RAYTRACING_INSTANCE_FLAG_TAPU4 ou D3D12XBOX_RAYTRACING_INSTANCE_FLAG_TAPU16 dans la description d’une instance, le générateur « remonte » directement dans la TLAS le premier (TAPU4) ou le deuxième (TAPU16) niveau de la hiérarchie de la BLAS. Cela permet en pratique de fractionner une grande instance de BLAS en 4 ou 16 nœuds, qui peuvent être partitionnés plus efficacement dans la hiérarchie de la TLAS, et d’éliminer les zones d’espace vide.
Pour obtenir des informations sur le « fractionnement d’instances » (Instance Splitting) ou le « Rebraiding », qui est une version automatisée de TAPU, consultez D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS3.
En plus de spécifier l’indicateur TAPU, des nœuds supplémentaires doivent être alloués dans la TLAS. Voici un exemple de code.
Options et indicateurs de génération
En plus de prendre en charge les indicateurs habituels des générateurs DXR commeD3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_TRACE, XDXR prend en charge une API permettant de spécifier des options supplémentaires pour les générateurs de BVH.
Consultez D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS1, D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS2, D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS3.
Il peut être avantageux de sacrifier du temps de génération de la TLAS au profit des performances de traversée, surtout si la génération de la TLAS peut être effectuée en calcul asynchrone. Consultez l’exemple 1 de la section Remarques de BuildRaytracingAccelerationStructureBatched2X pour un exemple de code qui augmente le nombre d’itérations de treelets pendant la génération de la TLAS. Cela peut améliorer considérablement les performances de traversée, au prix de temps de génération de la TLAS beaucoup plus longs.
