Skip to main content
XDXR est l’implémentation XBOX de l’API DirectX Raytracing (DXR) sur XBOX Series X|S. À l’exception (en date de novembre 2019) des nuanceurs appelables, XDXR représente un surensemble des fonctionnalités fournies par l’API DXR sur les PC Windows en date de la mise à jour de novembre 2019 de Windows 10. Pour cette rubrique, nous supposons que vous connaissez DXR. Nous vous recommandons fortement de lire la documentation de DXR et la spécification DXR de Windows.

Différences par rapport à DXR sur Windows

Lors de la création d’une signature racine globale, un indicateur supplémentaire doit être défini dans la description de la signature racine : D3D12XBOX_ROOT_SIGNATURE_FLAG_RAYTRACING. Cet indicateur ne peut actuellement pas être défini dans une signature racine spécifiée en langage de nuanceur de haut niveau (HLSL) et doit être défini dans le code avant la sérialisation de la signature racine. XDXR ne prend pas entièrement en charge la fonctionnalité RayQuery.TraceRayInline() de DXR 1.1; toutefois, nous fournissons un fichier d’en-tête (XDXRStandaloneTraverse) qui imite l’API RayQuery et devrait permettre un portage très simple pour la plupart du code RayQuery. Les différences particulières sont indiquées dans Parcours autonome XDXR. XDXR ne prend actuellement pas en charge RAY_FLAG_SKIP_TRIANGLES, RAY_FLAG_SKIP_PROCEDURAL_PRIMITIVES ni le système D3D12_RAYTRACING_PIPELINE_FLAGS. Cela pourrait être revu à l’avenir. Actuellement, les constructions de TLAS par lots peuvent être extrêmement rapides sur XBOX, et la construction de TLAS distinctes dans ce cas offrira de meilleures performances de parcours que le fait d’ignorer les nœuds. XDXR prend en charge plusieurs extensions permettant d’interroger l’état directement à partir du BVH ou du parcours, sans avoir à utiliser les données de charge utile pour le stockage. Pour utiliser ces extensions, déclarez à l’avance une ou plusieurs des fonctions suivantes en haut de votre nuanceur de lancer de rayons.

Conception de XDXR

À un niveau élevé, l’implémentation de XDXR peut être considérée comme divisée en deux parties : un cœur de parcours (Traversal Core) et le « planificateur » (Scheduler).

Cœurs de parcours

Un cœur de parcours est l’implémentation du parcours de la hiérarchie de volumes englobants (BVH) de XDXR. Il est responsable de la gestion du parcours et des décisions de haut niveau, comme le choix des nuanceurs (par exemple, closest-hit et any-hit) à appeler. Il ne s’occupe pas des mécanismes réels d’appel du nuanceur. Cela relève du planificateur. XDXR utilise une représentation BVH4 pour stocker ses structures d’accélération. Bien que d’autres formats de BVH auraient pu être choisis, ce format correspond à celui pour lequel XBOX Series X|S dispose de matériel personnalisé permettant d’effectuer des tests d’intersection rayon/boîte englobante alignée sur les axes (AABB). Pour plus de détails, consultez Conception matérielle du lancer de rayons.

Parcours

XDXR n’implémente actuellement aucune forme de réempaquetage, de tri ou de réorganisation des rayons. Dès qu’un nuanceur de génération de rayons est appelé, tout thread qui ne trace pas activement un rayon est une « voie inactive » dans la vague et gaspille des occasions d’effectuer du travail utile. Conceptuellement, un rayon est créé sur un thread donné. Tous les appels subséquents de nuanceurs ou de rayons récursifs résident sur ce même thread. Si un nuanceur de génération de rayons crée deux rayons sur la voie 0 et aucun rayon sur toutes les autres voies d’une vague, le thread 0 doit terminer séquentiellement ses deux rayons pendant que tous les autres threads restent inactifs. XDXR expose actuellement deux algorithmes de parcours de BVH. L’algorithme par défaut s’appelle parcours « divergent » (Divergent) et constitue la solution la plus générique, adaptée aux charges de travail divergentes comme les réflexions brillantes. Pour TraceRayInline(), l’en-tête équivalent est XDXRStandaloneTraverseShortStack.hlsli. Pour les charges de travail très cohérentes, comme les rayons d’ombre ou les réflexions non brillantes, le GDK de juin 2022 fournit un nouvel algorithme de parcours « hybride » (Hybrid). Cet algorithme effectue le parcours de la TLAS au moyen de branchements scalaires et ne diverge qu’à l’entrée d’une BLAS. Le parcours hybride peut offrir des performances considérablement améliorées pour certains contenus et certaines charges de travail de lancer de rayons. Pour activer le parcours « hybride », ajoutez XBOX_RAY_FLAG_COHERENT_RAYS_HINT aux indicateurs de rayon de votre TraceRay() DXR 1.0. Les indicateurs de rayon et le pointeur de TLAS doivent être uniformes pour activer ce type de parcours. Pour TraceRayInline(), l’en-tête équivalent est XDXRStandaloneTraverseHT.hlsli.

Planificateur

Le planificateur a la responsabilité de piloter la « boucle principale » de DXR. La conception de DXR est telle que la prise en charge des appels de fonction par pointeur (aussi appelés appels indirects) est requise, un concept qui n’est généralement pas associé aux architectures GPU. À l’avenir, la possibilité d’effectuer des appels de fonction en dehors de DXR/XDXR sera exposée pour un usage plus général. Lorsque vous déterminez la meilleure façon d’utiliser XDXR, il est important de tenir compte de l’incidence sur les performances d’une trop grande dépendance aux appels de fonction répétés. Les appels à TraceRay et à d’autres nuanceurs DXR nécessitent d’enregistrer et de recharger l’état des registres de chaque thread avant de sauter vers un nouveau morceau de code. L’enregistrement de l’état de chaque thread/rayon en mémoire et son rechargement ultérieur consomment une quantité considérable de bande passante chaque fois que cela se produit. À des résolutions plus élevées, si chaque rayon doit écrire et lire son état de registres ne serait-ce qu’une seule fois, cela pourrait finir par consommer des centaines de mégaoctets de mémoire si ce n’est pas géré correctement. Les besoins en bande passante liés à l’enregistrement et à la restauration de l’état des rayons éclipsent très rapidement le coût de la lecture réelle du BVH et des renseignements de matériau associés, comme les textures. L’accès total à la mémoire du lancer de rayons doit inclure la lecture du BVH, des textures, des index et des sommets, l’écriture d’une sortie basée sur une vue d’accès non ordonné (UAV) et la lecture/écriture de l’état des rayons pour faciliter les appels de fonction. C’est pour ces raisons que nous recommandons d’éviter autant que possible la récursion et les nuanceurs any-hit.

Compilation des nuanceurs

La compilation des nuanceurs en code machine s’effectue par collection. Toutes les fonctions qui peuvent être entièrement résolues sont compilées en code machine et utilisées par pointeur dans le planificateur. Les cœurs de parcours (fonctions de parcours) ne sont compilés qu’à la demande, en fonction de la taille maximale des attributs et de la présence ou non de nuanceurs d’intersection. Cela aide à réduire la taille de la mémoire, à accélérer la compilation et à améliorer l’utilisation du cache d’instructions. La précompilation des nuanceurs est possible, mais les nuanceurs de lancer de rayons précompilés ne fonctionneront qu’avec la version correspondante du planificateur et des cœurs de parcours. Cela est dû à une convention d’appel de fonction particulière utilisée par XDXR, qui peut changer à tout moment. Notre recommandation XBOX à ce sujet est encore à l’étude.

DispatchRays

Compte tenu de la quantité de mémoire nécessaire pour exécuter le planificateur XDXR (dans certains cas, un kilo-octet par rayon!) et en supposant pour l’instant que la taille de la mémoire de travail par rayon soit le seul facteur limitant l’occupation, alors pour maintenir une occupation de 1, nous devons exécuter environ 3 584 voies sur XBOX Series X. À tout moment, nous devons avoir plusieurs mégaoctets de mémoire de travail utilisés pour chaque lot de rayons. Un choix évident pour utiliser cette mémoire est la mémoire de travail système. Son utilité est toutefois limitée sur XBOX One : elle nécessite un vidage complet pour reprogrammer la taille de la mémoire de travail. Par conséquent, elle n’est pas prise en charge sur les canaux de calcul asynchrone. L’interpolateur de processeur de nuanceurs (SPI) ne prend pas en charge plus d’une vue de la mémoire de travail, donc cela ne fonctionnera pas. Par conséquent, DispatchRays utilise plusieurs répartitions pour traiter l’ensemble des rayons. Le pilote utilise une mémoire tampon de travail personnalisée qui défile à travers les petites répartitions DispatchRays. La taille de mémoire de travail disponible détermine le nombre de répartitions simultanées et, par conséquent, les performances du lancer de rayons. Des clôtures régulières sont utilisées pour empêcher les répartitions d’écraser la mémoire de travail personnalisée utilisée par d’autres vagues déjà en cours d’exécution. DispatchRaysX permet de spécifier une mémoire tampon de travail personnalisée. Cela est requis lors de l’exécution de charges de travail de lancer de rayons en calcul asynchrone. Notez que le parcours autonome XDXR en ligne ne nécessite pas de mémoire de travail et peut donc être exécuté en calcul asynchrone comme un nuanceur de calcul normal, sans traitement particulier.

Voir aussi

Vue d’ensemble du lancer de rayons (et de DXR)
Last modified on October 6, 2026