Passer au contenu principal
XDXR est l’implémentation XBOX de l’API DirectX Raytracing (DXR) sur XBOX Series X|S. À l’exception (en novembre 2019) des shaders appelables, XDXR représente un sur-ensemble des fonctionnalités fournies par l’API DXR sur les PC Windows à partir de la mise à jour de novembre 2019 de Windows 10. Dans cette rubrique, nous supposons que vous connaissez DXR. Nous vous recommandons vivement de lire la documentation DXR et la spécification DXR de Windows.

Différences avec 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 HLSL (High-Level Shader Language) 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 ; nous fournissons toutefois 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 spécifiques sont indiquées dans XDXR Standalone Traverse. 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 pourra être révisé à 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 des 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 (payload) pour le stockage. Pour utiliser ces extensions, déclarez à l’avance une ou plusieurs des fonctions suivantes en haut de votre shader de raytracing.

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 « Scheduler » (planificateur).

Cœurs de parcours

Un cœur de parcours est l’implémentation du parcours de la hiérarchie de volumes englobants (BVH) dans XDXR. Il est chargé de gérer le parcours et les décisions de haut niveau, comme le choix des shaders à appeler (par exemple, closest-hit et any-hit). Il ne s’occupe pas des mécanismes réels d’appel du shader : cette responsabilité incombe au Scheduler. 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 d’un matériel personnalisé effectuant les tests d’intersection rayon/boîte englobante alignée sur les axes (AABB). Pour plus d’informations, consultez Conception matérielle du raytracing.

Parcours

XDXR n’implémente actuellement aucune forme de réempaquetage, de tri ou de réorganisation des rayons. Dès qu’un shader de génération de rayons est invoqué, tout thread qui ne trace pas activement un rayon est une « voie inactive » dans la wave et gaspille des occasions d’effectuer un travail utile. Conceptuellement, un rayon est généré sur un thread donné. Toutes les invocations ultérieures de shaders ou de rayons récursifs résident sur ce même thread. Si un shader de génération de rayons génère deux rayons sur la voie 0 et aucun rayon sur toutes les autres voies d’une wave, 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, appelé parcours « Divergent », est 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 « Hybrid ». Cet algorithme effectue le parcours de la TLAS à l’aide de branchements scalaires, et ne diverge qu’à l’entrée dans une BLAS. Le parcours hybride peut offrir des performances nettement améliorées sur certains contenus et certaines charges de travail de raytracing. Pour activer le parcours « Hybrid », 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.

Scheduler

Le Scheduler est chargé de piloter la « boucle principale » de DXR. La conception de DXR exige la prise en charge des appels de fonction par pointeur (également appelés appels indirects), 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. Pour déterminer la meilleure façon d’utiliser XDXR, il est important de tenir compte de l’impact sur les performances d’un recours trop important aux appels de fonction répétés. Les appels à TraceRay et à d’autres shaders 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, puis son rechargement ultérieur, consomme une quantité considérable de bande passante à chaque fois. À 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 en l’absence d’une gestion appropriée. Les besoins en bande passante liés à l’enregistrement/la restauration de l’état des rayons dépassent très rapidement le coût de la lecture effective du BVH et des informations de matériau associées, comme les textures. L’accès mémoire total du raytracing doit inclure la lecture du BVH, des textures, des indices 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 permettre les appels de fonction. C’est pour ces raisons que nous recommandons d’éviter autant que possible la récursivité et les shaders any-hit.

Compilation des shaders

La compilation des shaders en code machine s’effectue par collection. Toutes les fonctions pouvant être entièrement résolues sont compilées en code machine et utilisées par pointeur dans le Scheduler. 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 de shaders d’intersection. Cela permet de réduire la taille mémoire, d’accélérer la compilation et d’améliorer l’utilisation du cache d’instructions. La précompilation des shaders est possible, mais les shaders de raytracing précompilés ne fonctionneront qu’avec la version correspondante du Scheduler et des cœurs de parcours. Cela est dû à une convention d’appel de fonction spécifique utilisée par XDXR, susceptible de changer à tout moment. Notre recommandation XBOX à ce sujet est encore à l’étude.

DispatchRays

Compte tenu de la quantité de mémoire nécessaire à l’exécution du Scheduler 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, il faut exécuter environ 3 584 voies sur XBOX Series X pour maintenir une occupation de 1. À tout moment, plusieurs mégaoctets de mémoire de travail doivent être utilisés pour chaque lot de rayons. Un choix évident pour cette mémoire est la mémoire de travail système (system scratch). Son utilité est cependant 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 pipes Async Compute. Le Shader Processor Interpolator (SPI) ne prend pas en charge plus d’une vue de la mémoire de travail, cette solution ne fonctionnera donc pas. Par conséquent, DispatchRays utilise plusieurs dispatches pour traiter l’ensemble des rayons. Le pilote utilise un tampon de mémoire de travail personnalisé qui est parcouru de manière circulaire par les petits dispatches de DispatchRays. La taille de mémoire de travail disponible détermine le nombre de dispatches simultanés et donc les performances du raytracing. Des fences régulières sont utilisées pour empêcher les dispatches d’écraser la mémoire de travail personnalisée utilisée par d’autres waves déjà en cours d’exécution. DispatchRaysX permet de spécifier un tampon de mémoire de travail personnalisé. C’est obligatoire lors de l’exécution de charges de travail de raytracing en calcul asynchrone. Notez que le parcours autonome XDXR inline ne nécessite pas de mémoire de travail et peut donc être exécuté en calcul asynchrone comme un shader de calcul normal, sans gestion particulière.

Voir aussi

Vue d’ensemble du raytracing (et de DXR)
Dernière modification le 6 octobre 2026