Générateur hors ligne
XDXR permet de générer les BVH hors ligne, de les compresser éventuellement, puis de les charger depuis le disque à l’exécution. Cela peut produire des BVH de meilleure qualité, pour de meilleures performances de parcours, et nécessite beaucoup moins de temps GPU que le générateur d’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 pouvant être mises à jour ainsi que les BLAS statiques. Un jeu typique est censé générer la plupart des BLAS hors ligne et n’effectuer que des générations de TLAS et des mises à jour de BLAS au cours d’une frame à l’exécution. Le générateur hors ligne peut effectuer un fractionnement des triangles afin d’éviter le coût des triangles longs, fins et inclinés, dont les boîtes englobantes peuvent être nettement plus grandes que leur surface. En outre, il peut réaliser une meilleure « quadification » des triangles dans les nœuds feuilles ; consultez la section « Quads » ci-dessous. Consultez l’exemple OfflineRT pour plus d’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 également 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 la version du GDK.Générations par lots
XDXR prend en charge les générations de BVH « par lots ». Générer ou mettre à jour plusieurs BVH en parallèle peut être de 10 à 25 fois plus rapide que de manière séquentielle. Consultez BuildRaytracingAccelerationStructureBatched2X. En outre, envisagez d’utiliser le calcul asynchrone pour superposer les générations de BVH à des charges de travail telles que les ombres. Il peut être possible de compenser la totalité du coût de génération, ou d’activer des options supplémentaires de qualité de génération pour un parcours plus rapide.FP16
Le test d’intersection de BVH RDNA2 prend en charge deux types de nœuds AABB : en 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 parcours, car la précision réduite provoque un gonflement des AABB. Une heuristique de gonflement des boîtes est utilisée pour déterminer quand ce 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 forcera toutes les AABB à utiliser FP16 et réduira les allocations pessimistes de BVH. Une valeur inférieure à 1.0f forcera toutes les AABB à utiliser FP32. Le même effet peut être obtenu 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 bonnes pratiques et les mêmes écueils en matière de performances que la plupart des autres générateurs de BVH à deux niveaux (TLAS + BLAS). Un problème courant concerne les grandes boîtes englobantes de BLAS remplies d’espace vide, ou fortement en intersection avec d’autres instances de BLAS. Si deux instances ont des boîtes englobantes qui se croisent, il peut être impossible pour le parcours de déterminer la position d’impact la plus proche sans parcourir 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 boîtes englobantes, auquel cas aucun tri ne peut être effectué. Parmi les objets particulièrement problématiques figurent par exemple les lignes électriques suspendues, qui ont probablement des boîtes englobantes très grandes par rapport au volume du maillage d’origine et sont susceptibles de couvrir de vastes zones de la scène. Un autre exemple est la combinaison de plusieurs petits objets en une seule BLAS : les limites s’étendent 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 à scinder ou à combiner des objets pendant les phases de création ou de modification du contenu. Cependant, cela peut être difficile, voire impossible, lors de l’ajout d’effets de lancer de rayons à des titres existants, ou à un stade avancé du pipeline de création du jeu. Pour offrir un certain degré de contrôle, XDXR implémente l’option « TAPU » (TLAS-Pull-Up) dans son générateur de BVH. Elle permet à l’utilisateur de marquer des instances individuelles comme nécessitant une « remontée » (pull-up) 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 « remontera » le premier (TAPU4) ou le deuxième (TAPU16) niveau de la hiérarchie de la BLAS directement dans la TLAS. Cela permet en pratique de scinder 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 de supprimer des zones d’espace vide.
Pour plus d’informations sur le « fractionnement d’instances » (Instance Splitting) ou le « retressage » (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. Un exemple de code suit.
Options et indicateurs de génération
En plus de prendre en charge les indicateurs habituels des générateurs DXR, tels queD3D12_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 intéressant de sacrifier du temps de génération de la TLAS au profit des performances de parcours, en particulier 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 augmentant le nombre d’itérations de treelets lors de la génération de la TLAS. Cela peut améliorer considérablement les performances de parcours, au prix de temps de génération de la TLAS beaucoup plus longs.
