> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# XDXR (XBOX DXR)

> XDXR (XBOX DXR)

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](https://microsoft.github.io/DirectX-Specs/d3d/Raytracing.html) et la [spécification DXR de Windows](/fr/build/core-features/graphics/directx-specs).

## 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](/fr/build/core-features/graphics/newfeatures/raytracing/rt-standalone).

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.

```cpp theme={null}
float XDXR_RayTCurrent();
float XDXR_RayTMin();​

// Extension -- retrieve the hit triangle vertex positions.
// Outparams are unchanged if there is no hit.
// Returns false if there is no hit.
bool XDXR_GetHitTriangleVertexPositions(
    out float3 v0,
    out float3 v1,
    out float3 v2,
    uint instanceNodePtr,
    uint leafNodePtr);

// Extension -- retrieve the committed hit triangle vertex positions.
// Use this after traversal to get the final hit triangle.
// Outparams are unchanged if there is no hit.
// Returns false if there is no hit.
bool XDXR_GetCommittedHitTriangleVertexPositions(
    out float3 v0,
    out float3 v1,
    out float3 v2);

// Extension -- retrieve the pending hit triangle vertex positions.
// Use this inside an AHS to get the candidate triangle.
// Outparams are unchanged if there is no hit.
// Returns false if there is no hit.
bool XDXR_GetPendingHitTriangleVertexPositions(
    out float3 v0,
    out float3 v1,
    out float3 v2);
​
uint XDXR_GetPendingBlasLeafNodePtr();
uint XDXR_GetPendingInstanceNodePtr();​

​uint XDXR_GetCommittedBlasLeafNodePtr();
uint XDXR_GetCommittedInstanceNodePtr();​

// Extension -- set leaf node to immediately run closest hit shader on.
// Use `rayFlags = RAY_FLAG_FORCE_OPAQUE | RAY_FLAG_FORCE_NON_OPAQUE` to force "short-circuit" traversal, immediately hitting this node.
void XDXR_SetShortCircuitIntersectNodes(uint instanceNode, uint blasLeafNodePtr);

// Example
{
    float maxT = 1E9;​

    RayDesc desc = { rayOrigin, minT, rayDir, maxT };​
    TraceRay(TLAS, flags, …, myRay, payload);​

    // No payload or Closest-Hit Shader required!​
    bool inShadow = XDXR_RayTCurrent() < 1E9;​

    // No need to fetch from your own vertex buffer.
    // Can use XDXR_GetPendingHitTriangleVertexPositions in AHS too​.
    float3 v0, v1, v2;​
    XDXR_GetCommittedHitTriangleVertexPositions(v0, v1, v2);

    // Perform shading logic.
    …
}
```

## 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](/fr/build/core-features/graphics/newfeatures/raytracing/rt-hardware-design).

### 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](/fr/reference/graphics/d3d12_xs/interfaces/ID3D12GraphicsCommandList6/methods/id3d12graphicscommandlist6_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](/fr/build/core-features/graphics/newfeatures/raytracing/rt-standalone) 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)](/fr/build/core-features/graphics/newfeatures/raytracing/rt-overview)


## Related topics

- [Lancer de rayons sur XBOX Series X|S avec XDXR](/fr/build/core-features/graphics/newfeatures/raytracing/index.md)
- [Répertoire des rubriques NDA : liens actifs vers Microsoft Learn](/fr/nda/nda-topic-directory.md)
- [Accéder aux ressources et téléchargements du GDK](/fr/home/onboarding-access/access-resources.md)
- [D3D_SHADER_MODEL](/fr/reference/graphics/d3d12/enums/d3d_shader_model_public.md)
- [Index des rubriques NDA pour le développement sur console avec le GDK XBOX](/fr/nda/nda-overview.md)