> ## 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.
# Ombrage à taux variable et éclairage clairsemé
> Ombrage à taux variable et éclairage clairsemé
Cette rubrique décrit l'ombrage à taux variable (VRS) et l'éclairage clairsemé. VRS est une nouvelle fonctionnalité matérielle et logicielle de Direct3D 12 qui permet de répartir les performances/la puissance de rendu à des taux variables sur une image rendue. Cette fonctionnalité permet d'améliorer les performances. Visuellement, la réduction du taux d'ombrage n'a que peu ou pas d'effet sur la qualité de sortie perceptible.
Le Microsoft Game Development Kit (GDK) de novembre 2019 pour XBOX Series X|S inclut la prise en charge de VRS Tier 2 sur le matériel XBOX Series X|S.
Ces informations étaient à jour en novembre 2019. Plusieurs fonctionnalités ont pu être modifiées ou mises à jour depuis.
## Introduction : VRS
La sortie en 1080p et les résolutions supérieures ont conduit au développement de techniques de rendu qui réduisent la charge d'ombrage des pixels. Ces techniques sont notamment les suivantes :
* Rendu fovéal en réalité virtuelle
* Rendu en damier
* Mise à l'échelle temporelle
VRS était l'étape logique suivante de cette évolution. VRS pour PC est sorti en mars 2019. Il est actuellement disponible sur DirectX 12 et Windows 10 grâce aux technologies Intel Ice Lake (Tier 1) et NVIDIA Turing (Tier 2). AMD produit des cartes graphiques améliorées pour PC basées sur la nouvelle microarchitecture RDNA2 pour la période des fêtes 2020.
Pour plus d'informations sur VRS, consultez les ressources suivantes :
**Microsoft Game Dev**
* [Variable Rate Shading Update XBOX Series Consoles](https://www.youtube.com/watch?v=pPyN9r5QNbs)
* [Tier 2 Variable Rate Shading in Gears](https://www.youtube.com/watch?v=-exWLpgnOJ4)
**Game Developers Conference (GDC) 2019**
* Microsoft : [Boost Rendering Performance with Variable Rate Shading](https://www.youtube.com/watch?v=f-SklVb2MDI)
* Microsoft : [DirectX: Variable Rate Shading, A Deep Dive](https://www.youtube.com/watch?v=2vKnKba0wxk)
* NVIDIA : [Adaptive Shading Overview](https://www.gdcvault.com/browse/gdc-19/play/1026205)
**Siggraph 2019**
* Intel : [Using Variable Rate Shading to improve the user experience](https://www.intel.com/content/www/us/en/developer/videos/use-variable-rate-shading-vrs-to-improve-the-user-experience-in-real-time-game-engines.html)
**Publications**
* [Visually Lossless Content and Motion Adaptive Shading in Games](http://www.leiy.cc/publications/nas/nas-pacmcgit.pdf)
**Exemples**
* [PC GitHub : exemple d'ombrage à taux variable Direct3D 12](https://github.com/microsoft/DirectX-Graphics-Samples/tree/develop/Samples/Desktop/D3D12VariableRateShading)
### Objectifs de conception de VRS
1. Des taux d'ombrage sélectionnables localement pour affiner l'équilibre entre la qualité du jeu et les performances :
* Qualité maximale là où c'est nécessaire.
* Demi-taux, le même taux que le rendu en damier.
* Quart de taux, voire moins.
2. La profondeur, le stencil et la couverture sont toujours à taux plein, avec des bords parfaits.
3. VRS est facile à intégrer dans un moteur existant en utilisant les mêmes shaders, que VRS soit activé ou non.
4. Aucun remplissage de trous, aucune passe ni aucun tampon supplémentaire, et aucune approximation.
5. L'aspect doux et cinématographique n'est pas imposé. Des visuels extrêmement nets sont possibles.
6. Compatible avec la mise à l'échelle temporelle et l'anticrénelage multi-échantillon (MSAA).
### Évolutivité locale
VRS peut réduire de manière sélective le taux d'ombrage dans les zones présentant des détails de texture basse fréquence. Par exemple :
* Les zones floues, comme la profondeur de champ, le flou de mouvement et le bloom
* Les situations de faible éclairage ou de saturation lumineuse
* L'occlusion partielle, comme les transparences, le brouillard, l'eau, les nuages, l'arrière du feuillage ou les éléments d'affichage tête haute (HUD)
* Les détails de texture basse fréquence, comme les particules et les transparences en demi-résolution
Les zones qui ne sont généralement pas remarquées. Par exemple :
* Les bords de l'écran
* Les zones sûres du suivi oculaire en réalité virtuelle
* Les objets en mouvement rapide
**Figure 1. Les taux d'ombrage contrôlent les invocations du pixel shader (PS) par pixel.**
La figure 1 montre quatre taux d'ombrage VRS.
* Taux 1 × 1 : une invocation PS par pixel. Chaque pixel est ombré.
* Taux 2 × 1 : une demi-invocation PS par pixel. Plus de détails verticalement.
* Taux 1 × 2 : une demi-invocation PS par pixel. Plus de détails horizontalement.
* Taux 2 × 2 : un quart d'invocation PS par pixel. Quart de taux.
Spécifiez le taux d'ombrage à l'aide de l'une des méthodes suivantes.
### Sources du taux d'ombrage
Il existe trois façons de spécifier le taux d'ombrage.
* Par appel de dessin :
* Tier 1 sur les PC Windows.
* [RSSetShadingRate](/fr/reference/graphics/d3d12/interfaces/id3d12graphicscommandlist5/methods/id3d12graphicscommandlist5_rssetshadingrate_public) définit le taux d'ombrage de base et les combinateurs pour VRS.
* Par vertex déclencheur ou par primitive :
* Tier 2 sur les PC Windows et XBOX Series X|S.
* Exportation à l'aide de [SV\_ShadingRate](/fr/build/core-features/graphics/newfeatures/vrs/vrs-feature).
* Carte de l'espace écran :
* Tier 2 sur les PC Windows et XBOX Series X|S.
* [RSSetShadingRateImage](/fr/reference/graphics/d3d12/interfaces/id3d12graphicscommandlist5/methods/id3d12graphicscommandlist5_rssetshadingrateimage_public) définit l'image du taux d'ombrage de l'espace écran pour VRS.
* `R8_UINT` par tuile, contenant des énumérations [D3D12\_SHADING\_RATE](/fr/reference/graphics/d3d12/enums/d3d12_shading_rate_public).
* L'application interroge la taille de tuile, parmi 8 × 8, 16 × 16 ou 32 × 32.
**Figure 2. Sources et combinateurs du taux d'ombrage.**
La figure 2 montre un exemple de sources et de combinateurs comportant trois sources et un ensemble de deux combinateurs.
1. Le premier combinateur prend les taux d'ombrage de l'appel de dessin et l'exportation du vertex par paramètre ou du vertex déclencheur.
2. Le second combinateur prend les résultats du premier combinateur et les combine avec la carte de l'espace écran.
3. Le taux d'ombrage final est transmis au rastériseur.
**Figure 3. API de combinateur.**
La figure 3 montre les appels de l'API de combinateur de la figure 2. Configurez les combinateurs pour obtenir les résultats souhaités.
**Figure 4. Résultat VRS.**
La figure 4 montre une scène rendue avec un taux variable en 4K, une taille de tuile de 8 × 8 et sans anticrénelage temporel (TAA). Cette scène a été rendue avec de nombreuses réductions du taux d'ombrage.
**Figure 5. Taux d'ombrage par tuile.**
La figure 5 montre la même scène avec un filtre de Sobel et un vote par tuile.
Le taux 1 × 1 est en rouge. Le taux 2 × 1 est en cyan et présente davantage de détails verticaux, montrant les détails de texture des murs à gauche et à droite. Le taux 1 × 2 est en jaune et présente davantage de détails horizontaux. Le taux 2 × 2 est en noir.
**Figure 6. Zone agrandie.**
La figure 6 agrandit les pierres du mur du fond de la figure 5 dans une zone de 160 × 168 pixels. Cela représente environ 0,3 % de la scène 4K d'origine.
* Le signal VRS se trouve sur la gauche de la figure 6.
* L'image de *référence*, entièrement rendue au taux 1 × 1, se trouve au milieu de la figure 6.
* Les images du taux d'ombrage et de l'erreur absolue se trouvent sur la droite de la figure 6.
**Figure 7. Zone agrandie : taux 1 × 1.**
La figure 7 montre où le shader qui générait le taux d'ombrage a utilisé le taux 1 × 1 complet. Notez que cela a été fait dans les zones à fort contraste. Notez également que le shader a repéré la réflexion spéculaire sur le dessus des pierres concernées.
**Figure 8. Zone agrandie : taux 2 × 2.**
La figure 8 montre où le shader a utilisé le taux 2 × 2 sur la surface des pierres. Notez la réduction de la qualité d'ombrage pour le signal VRS.
**Figure 9. Zone agrandie : plusieurs taux d'ombrage.**
La figure 9 montre les zones où plusieurs taux d'ombrage ont été utilisés sur les sections endommagées de la surface des pierres.
**Figure 10. Zone agrandie : demi-taux.**
La figure 10 montre les zones où l'ombrage à demi-taux a été utilisé. Il est utile pour préserver les détails dans une zone particulière. Sans ombrage à demi-taux, vous devez utiliser l'ombrage à taux plein.
**Figure 11. Quelle quantité d'ombrage avons-nous effectuée ?**
La figure 11 montre la quantité d'ombrage effectuée lors du rendu de l'écran. La section agrandie mesure 20 × 21 tuiles (160 × 168 pixels).
* 94 tuiles à taux plein (rouge)
* 143 tuiles à demi-taux (cyan/jaune)
* 183 tuiles à quart de taux (noir)
Invocations PS à 8 × 8 pixels par tuile :
* Sans VRS = 26 880 threads PS
* Avec VRS = 13 520 threads PS
* Invocations PS divisées par le nombre de pixels = 0,503
### Dérivation de la carte de l'espace écran
Nous vous recommandons d'utiliser l'image précédente pour prédire l'image actuelle. Par exemple, l'image précédente vous indique :
* Où vous appliquerez la profondeur de champ.
* Où le flou de mouvement se produit.
* Qu'il existe une zone de faible éclairage ou une zone de saturation lumineuse.
Résumé de l'exemple précédent (figure 4 à figure 11) :
* Démarrage avec un filtre de Sobel.
* Les résultats ont été obtenus sans reprojection de mouvement.
* Les noyaux de convolution X et Y ont été vérifiés par rapport au gradient et à la luminance, puis comparés à un taux.
* Vote par tuile sur le taux d'ombrage à utiliser.
* Si le résultat de la comparaison est non nul pour X ou Y, le taux est de 2 × 1 ou 1 × 2.
* Nous vous recommandons d'utiliser des intrinsèques inter-voies.
Le résultat est un processus avec une surface d'API réduite, sans modification des shaders et sans modification du MSAA. Une passe de reconstruction n'est pas nécessaire. La surface VRS est complète et prête pour le rendu.
Pour un filtre mis à jour, consultez l'exemple VRSandSparseLighting dans les [exemples pour console du Microsoft GDK](https://learn.microsoft.com/gaming/gdk/docs/gdk-dev/development-downloads/gdk-samples-list#graphics).
**Figure 12. Modification de l'emplacement d'invocation PS.**
La figure 12 compare l'image de référence au taux 1 × 1 avec un signal VRS de la même scène.
VRS modifie l'emplacement d'invocation PS, ce qui peut créer des problèmes. Par exemple :
* VRS peut capturer des détails absents de l'image de référence.
* Différents taux d'ombrage peuvent capturer ou manquer des détails inférieurs au pixel.
Les détails inférieurs au pixel, ou le sous-échantillonnage, peuvent poser problème.
* Crénelage temporel lorsque la caméra se déplace :
* Dans cet exemple, des problèmes de crénelage temporel apparaissent même sans VRS.
* Les taux grossiers de VRS peuvent aggraver le sous-échantillonnage.
* Les gradients de texture sont plus longs pour chaque axe grossier.
* La sélection d'un mip inférieur est automatique et améliore le crénelage.
* L'utilisation de niveaux de détail (LOD) de maillage améliore les performances.
* Soyez prudent lors de l'utilisation du crénelage de shader.
* Utilisez TAA pour résoudre les problèmes de rendu liés au sous-échantillonnage.
### Taux d'ombrage
Les taux 1 × 1, 2 × 1, 1 × 2 et 2 × 2 constituent l'ensemble minimal de fonctionnalités de VRS. Les PC disposent d'une capacité supplémentaire grâce à [AdditionalShadingRatesSupported](/fr/build/core-features/graphics/newfeatures/vrs/vrs-feature), qui prend en charge les taux d'ombrage 2 × 4, 4 × 2 ou 4 × 4. Les taux 2x semblent être les plus efficaces. Avec les taux 2x, il peut être difficile de constater une dégradation de la qualité. C'est particulièrement vrai pour les taux 2 × 1 et 1 × 2. Avec les taux 4x, les différences de rendu sont beaucoup plus visibles, mais ils sont plus difficiles à utiliser. Les avantages en matière de performances diminuent avec les taux 4x.
Voici les résultats de performances NVIDIA Tier 2 avec la carte de l'espace écran.
**Wolfenstein II: The New Colossus**
* Le mode équilibré offre une amélioration de 6 % du nombre d'images par seconde (FPS).
* Le mode performances offre une amélioration de 9 à 10 % du FPS.
* Source : Digital Foundry
**Civilization VI**
* Réduction de 8 à 17 % du temps d'image global.
Pour connaître les gains de performances de DOOM Eternal et Gears 5 et obtenir des informations mises à jour, consultez la vidéo suivante :
[Variable Rate Shading Update XBOX Series Consoles](https://www.youtube.com/watch?v=pPyN9r5QNbs).
## VRS Tier 2.x sur XBOX Series X|S
### Prise en charge des consoles XBOX Series X|S
Les consoles XBOX Series X|S ont implémenté la spécification PC Tier 2 dans le Microsoft Game Development Kit (GDK) de novembre 2019, avec les fonctionnalités et exceptions suivantes.
Fonctionnalités :
* Taux d'ombrage 1 × 1, 1 × 2, 2 × 1 et 2 × 2
* Carte de l'espace écran
Exceptions :
* Aucune capacité de mode 4x.
* La sortie du masque de couverture est actuellement incorrecte si vous utilisez MSAA. Un correctif est prévu pour ce problème de sortie.
* L'entrée [SV\_Coverage](/fr/build/core-features/graphics/newfeatures/vrs/vrs-feature) fonctionne correctement.
* Le matériel n'implémente pas de centroïde conforme à la spécification.
* La [vue de cible de rendu](/fr/reference/graphics/d3d12/structs/d3d12_render_pass_render_target_desc_public) (RTV) est autorisée sur la carte d'image du taux d'ombrage.
### Extensions XBOX de XBOX Series X|S
La prise en charge est prévue pour :
* Le super-échantillonnage avec MSAA.
* Les décalages de position des échantillons.
* Des combinateurs supplémentaires.
* Le taux d'ombrage par primitive avec plusieurs fenêtres d'affichage.
* L'exportation du taux d'ombrage depuis le domain shader.
* La surface de retour du taux d'ombrage.
Faites-nous part de vos priorités en matière de fonctionnalités sur les forums du Microsoft Game Development Kit (GDK).
### Super-échantillonnage avec MSAA
XBOX Series X|S prend en charge les taux d'ombrage de super-échantillonnage 2x et 4x. Par exemple, ils sont utilisés en MSAA 8x. L'ensemble des invocations PS possibles par pixel est le suivant.
* 0,25
* 0,5
* 1
* 2
* 4
* 8
Une invocation PS par taux 2 × 2 est le taux le plus grossier possible. Avec le MSAA 8×, il s'agit en pratique d'un taux de 1/32, soit 1 invocation PS diffusée à 4 pixels × 8 échantillons.
**Figure 13. Matrice complète des taux d'ombrage de XBOX Series X|S.**
La figure 13 montre une matrice des taux d'ombrage de XBOX Series X|S qui tient compte du domaine de super-échantillonnage. La matrice indique le nombre d'invocations PS par pixel. Notez qu'il n'existe aucun mode rectangulaire dans le domaine de super-échantillonnage.
### HTile et la carte de l'espace écran
Sur XBOX Series X|S, le taux d'ombrage est écrit dans une carte de l'espace écran, qui est ensuite transcodée en [HTile](/fr/reference/graphics/d3d12_xs/enums/d3d12xbox_shading_rate_settings_htile_mode_type), où le rastériseur lit le taux d'ombrage.
* La taille de tuile est toujours de 8 × 8. Aucune requête n'est nécessaire.
* La tuile est lue pendant la rastérisation. Aucune bande passante supplémentaire n'est nécessaire.
* Une extension XBOX pourrait effectuer un effacement de profondeur et définir la carte du taux d'ombrage en une seule passe. Cela améliore les performances.
#### Deux nouveaux encodages HTile
Deux nouveaux encodages HTile avec Stencil sont désormais disponibles.
* Sans prise en charge du taux d'ombrage de super-échantillonnage :
* Les bits libres 10-11 du Stencil HTile sont utilisés pour stocker le taux d'ombrage.
* Avec prise en charge du taux d'ombrage de super-échantillonnage :
* Quatre bits sont nécessaires pour le taux d'ombrage. HTile perd son second pré-test Hi-Stencil (bits 6-7). Le premier pré-test est conservé.
Dans le Microsoft Game Development Kit (GDK) de novembre 2019, tous les HTiles utilisent le second encodage. À l'avenir, attendez-vous à un indicateur de ressource « jamais VRS » qui renvoie un format HTile « sans stencil » pour plus de précision. La prise en charge du premier format HTile sera ajoutée au Microsoft Game Development Kit (GDK).
### Détails d'implémentation sur XBOX Series X|S
Lorsque `RSSetShadingRateImage` est appelée, elle transcode le contenu en HTile. En l'absence de HTile lié, un HTile temporaire est alloué à partir de l'allocateur de commandes de la liste de commandes. Cela permet d'utiliser VRS sans profondeur. VRS peut être utilisé pour des opérations comme le post-traitement. Si l'allocation échoue par manque de mémoire, VRS est désactivé.
Si vous modifiez la vue de stencil de profondeur (DSV), nous vous recommandons d'appeler d'abord `RSSetShadingRateImage(nullptr)`. Sinon, vous risquez de payer à nouveau le coût de transcodage si la DSV a les mêmes dimensions.
Une RTV supérieure à 4K échoue. Un correctif pour ce problème est prévu pour le Microsoft Game Development Kit (GDK) d'avril 2020.
### XBOX Series X|S dispose de combinateurs supplémentaires
**Figure 14. XBOX Series X|S dispose de combinateurs supplémentaires.**
La figure 14 montre les combinateurs supplémentaires de XBOX Series X|S. Nous pouvons les exposer s'il existe une demande.
### Emplacement d'invocation PS
Le matériel XBOX Series X|S prend en charge les décalages d'échantillon centre, centroïde et programmables, qui peuvent modifier l'emplacement d'invocation du pixel shader.
* Décalage de 4 bits pour chaque taux d'ombrage
* L'emplacement auquel le PS est invoqué peut changer à chaque cycle d'image
### Incompatibilités de VRS
Certains éléments sont incompatibles avec VRS et le désactivent sur XBOX Series X|S. Cela se produit lorsque l'emplacement du PS ne s'aligne pas sur l'échantillon de profondeur ou l'échantillon de stencil.
* Masque de couverture post-profondeur
* [Raster Order Views](/fr/build/core-features/graphics/newfeatures/vrs/vrs-feature) (ROV)
* Importation de [SV\_Depth](/fr/build/core-features/graphics/newfeatures/vrs/vrs-feature)
* Passez plutôt par un interpolateur. Consultez la définition du compilateur de shaders `__XBOX_SV_POS_ZW_VIA_ATTRIBUTE`, qui s'en charge pour vous.
* Écriture de `SV_Depth` ou de [SV\_StencilRef](/fr/build/core-features/graphics/newfeatures/vrs/vrs-feature)
### Extension Shading Rate Feedback Surface
L'extension Shading Rate Feedback Surface effectue les opérations suivantes :
* Prend 2 bits de [cmask](/fr/build/core-features/graphics/overviews/cmask-decoding)
* Enregistre si un triangle a été rendu à un taux fin ou grossier sur chaque axe
* Supprime la fonctionnalité d'effacement rapide de `cmask`
* Est incompatible avec le processus `cmask` de composition rapide
### Récapitulatif de la prise en charge des plateformes
**Figure 15. Prise en charge des plateformes.**
La figure 15 montre la prise en charge des fonctionnalités pour chaque plateforme.
Ces informations étaient à jour en novembre 2019. Plusieurs fonctionnalités ont pu être modifiées ou mises à jour depuis.
Tenez compte des points suivants :
* XBOX Series X|S prend en charge le plus grand nombre d'ensembles de fonctionnalités.
* Avec de petits éléments, il est préférable d'utiliser des tuiles 8 × 8 plutôt que des tuiles 16 × 16, car elles augmentent le taux d'ombrage pour moins de pixels.
## Optimisations des performances matérielles de XBOX Series X|S
Les améliorations des performances de XBOX Series X|S doivent s'accompagner d'une réduction des charges du pixel shader.
### Opérations du bloc de couleur
Dans le pipeline graphique logique, un bloc de couleur est l'une des deux dernières opérations logiques avant la sortie de rendu.
**Chemins lents**
Lorsque la RTV dépasse 32 bits par pixel (bpp) ou que le mélange est activé :
* Sans VRS, il y a 4 pixels par cycle d'horloge par back-end de rendu (RB).
* Avec VRS, il y a 4 pixels par cycle d'horloge par RB. Toutefois, la diffusion du grossier vers le fin nécessite *n* cycles supplémentaires, où *n* correspond au nombre de pixels couverts.
**Chemins rapides**
Lorsque la RTV est inférieure ou égale à 32 bpp et que le mélange n'est pas activé :
* Sans VRS, vous pouvez utiliser le back-end de rendu optimisé (RB+) avec un taux 2x, soit 8 pixels par cycle d'horloge par RB.
* Avec VRS, il y a 4 pixels par cycle d'horloge par RB pour un taux 1 × 1.
* Toutefois, le bloc de couleur peut charger latéralement des copies de diffusion supplémentaires.
* 4 pixels par cycle d'horloge pour un taux 2 × 1.
* 8 pixels par cycle d'horloge pour un taux 1 × 2.
* 8 pixels par cycle d'horloge pour un taux 2 × 2.
Il existe un plafond de 16 pixels par cycle d'horloge par RB.
Le travail du pixel shader est désormais amélioré, car le bloc de couleur peut traiter des copies supplémentaires.
### RSSetShadingRate
Pour utiliser RB+, désactivez VRS en appelant `RSSetShadingRate(D3D12_SHADING_RATE_1x1, nullptr);`. Notez que `RSSetShadingRate` ne provoque pas de changement de contexte (roll).
### VRS et compression delta des couleurs
La compression delta des couleurs (DCC) dispose désormais d'un mode compatible VRS qui réduit la bande passante.
* VRS génère un signal qui se compresse mal avec la DCC classique.
* Exemple de signal : ancre, delta, delta nul, delta, delta nul. Répétition.
* Un mode compatible VRS a été ajouté à la DCC.
* Optimisé pour une compression proche de 4:1 sur le taux 2 × 2.
* Ratios nettement améliorés pour les taux 2 × 1 et 1 × 2.
## Éclairage clairsemé
VRS écrit des valeurs de g-buffer en double et les éclaire. Le traitement des données de g-buffer en double est un gaspillage.
### Éclairage clairsemé : exploitation du signal VRS
Pour éviter de gaspiller des performances, examinez les g-buffers à la recherche de valeurs en double, puis identifiez et éclairez uniquement un sous-ensemble de pixels. Par exemple, dans un quad de 2 × 2 pixels :
* 1 pixel pour un taux 2 × 2
* 2 pixels pour un taux 1 × 2 ou 2 × 1 (motif en damier)
* 4 pixels pour un taux 1 × 1
### Exemple d'implémentation de l'éclairage clairsemé
Voici un exemple qui utilise une taille de tuile de 16 × 16 et une taille de groupe de 8 × 8.
1. Le thread du compute shader compare les valeurs du g-buffer par blocs de 2 × 2 pixels.
2. Il écrit ensuite de 1 à 4 coordonnées par thread. Chacune comporte 32 bits par coordonnée.
* 4 bits pour la coordonnée x relative à la tuile.
* 4 bits pour la coordonnée y relative à la tuile.
* 3 bits indiquant s'il faut copier la valeur en x, en y ou en diagonale (pour remplir les trous).
* 21 bits suffisent pour une valeur de profondeur.
3. L'une des sorties est le nombre d'opérations d'éclairage nécessaires par tuile d'écran.
Pour obtenir des informations mises à jour, consultez les ressources suivantes :
[Variable Rate Compute Shaders - Halving Deferred Lighting Time](https://www.youtube.com/watch?v=Sswuj7BFjGo).
[Exemple VRSandSparseLighting](https://learn.microsoft.com/gaming/gdk/docs/gdk-dev/development-downloads/gdk-samples-list#graphics).
### Shader d'éclairage différé
Le shader d'éclairage différé distribue désormais une wave par thread de tuile au lieu d'un thread par pixel.
1. La wave effectue *n* boucles sur `tileCount`. Les performances s'améliorent lorsque vous supprimez des opérations d'éclairage équivalentes ou supérieures au travail d'une wave. En comparant les performances de Wave32 et de Wave64 :
* Wave32 produit une accélération lorsqu'il y a 224 pixels ou moins à éclairer.
* Wave64 produit une accélération lorsqu'il y a 194 pixels ou moins à éclairer.
2. Le thread lit 32 bits, en décompressant coordinate.xy et la profondeur.
3. Effectuez l'éclairage comme vous le feriez habituellement. Les listes de lumières restent invariantes par wave.
4. Terminez par un maximum de trois copies diffusées du résultat éclairé.
* Un bit pour chaque copie horizontale, verticale et diagonale.
* XOR1 est utilisé pour calculer destination.xy pour chacune des trois copies.
* Le remplissage des trous est parfait, précalculé et peu coûteux.
**Figure 16. Résultat de l'éclairage clairsemé et nombre d'opérations d'éclairage.**
La figure 16 montre à gauche une image 4K d'une tête de lion en pierre éclairée de manière clairsemée. Le tampon de comptage se trouve à droite. Il montre une diminution significative des opérations d'éclairage. Les g-buffers de la pierre ont été testés à la recherche de valeurs strictement identiques avec une faible plage de profondeur autorisée (delta LinearZ autorisé de 0,001).
**Figure 17. Résultat éclairé, sans remplissage des trous.**
La figure 17 montre une image agrandie de l'œil du lion sans remplissage des trous.
* Les trous sont les pixels noirs.
* 1 × 1 : chaque échantillon est éclairé.
* 2 × 1 et 1 × 2 ressemblent tous deux à des damiers.
* 2 × 2 éclaire un échantillon sur quatre.
Notez que le maillage filaire est visible. Le problème ici est que le taux d'ombrage demandé n'est pas nécessairement le taux d'ombrage appliqué.
Par exemple, considérez un quad de 2 × 2 pixels ombré au taux 2 × 2. Cela peut générer d'une à quatre invocations PS sans surdessin.
* Une invocation si le quad de pixels est couvert par un seul triangle.
* Quatre invocations si le quad est couvert par quatre triangles.
Des LOD de maillage médiocres donnent de mauvais résultats VRS.
**Figure 18. Comparaison du g-buffer avec un delta ajouté de 0,025.**
La figure 18 montre le résultat de l'ajout d'un petit delta autorisé dans les valeurs lors de la comparaison du g-buffer. Les valeurs des normales sont à gauche. Les valeurs d'albédo sont à droite. L'ajout de ce petit delta a réduit le nombre d'opérations d'éclairage et éliminé le maillage filaire. La luminance de ces images correspond en partie au nombre de calculs d'éclairage. On se rapproche ainsi de l'ensemble optimal de pixels à éclairer : 1, 2, 3 ou 4 par taux 2 × 2.
**Figure 19. Correspondance exacte du g-buffer.**
La figure 19 montre l'image de la tête de lion avec les trous remplis. Il est difficile de faire la différence entre les deux, même agrandies.
### Examen du g-buffer avec des optimisations propres à XBOX Series X|S
Il existe une implémentation améliorée qui n'implique pas l'examen du contenu du g-buffer. Pour plus d'informations, consultez la vidéo et l'exemple suivants.
[Variable Rate Compute Shaders - Halving Deferred Lighting Time](https://youtu.be/Sswuj7BFjGo?t=859)
Exemple [VRSandSparseLighting](https://learn.microsoft.com/gaming/gdk/docs/gdk-dev/development-downloads/gdk-samples-list#graphics)
L'examen du g-buffer est coûteux. Les optimisations propres à XBOX Series X|S sont notamment les suivantes :
1. Lisez la carte du taux d'ombrage. Utilisez le chemin rapide pour les tuiles à taux plein et traitez chaque pixel.
2. Tirez parti de la surface `cmask` de retour du taux d'ombrage. Utilisez le chemin rapide pour les tuiles à taux réduit couvertes par un seul triangle.
3. Pour les tuiles restantes :
1. Lisez la clé DCC, puis exploitez les deltas nuls.
2. Effectuez un examen du g-buffer.
* Utilisez le hachage du g-buffer pour l'optimisation. Cela se fait au prix du stockage et de la bande passante.
* Combinez la lecture du g-buffer avec des passes qui effectuent une autre opération, comme la lecture de la profondeur.
**Figure 20. Économies de l'éclairage clairsemé par rapport à l'éclairage différé classique en 4K.**
La figure 20 montre des rendus de scènes qui comparent les économies de l'éclairage clairsemé à l'éclairage différé en 4K.
* `cmask` et DCC n'ont pas été utilisés dans ces scènes.
* La figure n'inclut pas les économies liées à VRS ni au temps de rastérisation.
* La discontinuité de profondeur autour des piliers entraîne une partition de profondeur importante et un nombre de lumières plus élevé.
* Dans la scène du bas, le nombre de lumières est relativement faible.
* La scène du haut présente le temps total écoulé le plus élevé. La scène du bas présente le temps total écoulé le plus faible. Les améliorations évoluent favorablement avec la complexité de la scène.
## Intégration avec d'autres techniques
### VRS, mise à l'échelle dynamique de la résolution et mise à l'échelle temporelle
VRS ne remplace pas la mise à l'échelle dynamique de la résolution (DRS).
* Il est possible de réduire le taux d'ombrage lorsque le temps d'image dépasse le temps d'image cible.
* Les améliorations apportées par VRS sont imprévisibles. Elles dépendent du contenu de la scène. L'éclairage fait partie des autres facteurs.
* DRS a un effet plus important et plus prévisible sur le temps d'image.
Les améliorations apportées par VRS sont un bonus.
* Ne remplacez pas DRS. Aidez plutôt DRS à atteindre des résolutions plus élevées.
* Utilisez la mise à l'échelle temporelle pour la résolution de sortie.
**Figure 21. VRS et rendu en damier sur XBOX Series X|S.**
La figure 21 compare VRS et la technique de rendu en damier sur XBOX Series X|S.
### Facteurs de performances de VRS
Les performances de VRS dépendent de plusieurs facteurs. Ils comprennent les suivants :
* L'efficacité de la rastérisation. Le parallax mapping, le relief mapping et le cone-step mapping sont à privilégier.
* Le contenu de la scène.
* La surcharge liée au calcul du taux d'ombrage.
* Le coût du PS et les goulots d'étranglement matériels en aval.
* Vos préférences personnelles entre performances et qualité.
### Taux d'ombrage par triangle/par appel de dessin
Les taux d'ombrage par triangle/par appel de dessin constituent une excellente amélioration des performances. Ils réduisent le coût GPU par rapport à la carte de l'espace écran.
**Par appel de dessin :**
* Les particules et les objets en mouvement rapide sont rendus dans la carte de réflexion.
* Déterminez si l'objet se trouve derrière une surface translucide.
**Par triangle :**
* Déterminez si le triangle se trouve de l'autre côté d'une surface d'eau par rapport à la caméra.
* Déterminez si le triangle est occulté par du feuillage ou un autre objet.
## Projets futurs
### XBOX uniquement
* Supprimer la carte de l'espace écran.
* Écrire le taux d'ombrage directement dans HTile.
* Effectuer un effacement de profondeur dans la même opération.
* Faire pivoter les décalages d'échantillon à chaque image.
* Cela produit une convergence semblable au damier, mais offre une couverture parfaite.
### PC et XBOX
* Combiner la détermination du taux d'ombrage avec un shader de post-traitement.
* Pour les taux inférieurs à 1 × 1, mais pas tout à fait 2 × 2, procédez comme suit :
* Envisagez d'alterner les taux 2 × 1 et 1 × 2 à chaque image, en particulier pour les titres à 60 hertz.
* Cela produit un motif en damier où les cases noires reçoivent 2 × 1 dans la première image et 1 × 2 dans l'image suivante. Les cases blanches reçoivent 1 × 2 dans la première image et 2 × 1 dans l'image suivante.
* Utilisez un jitter TAA grossier au lieu d'un jitter TAA inférieur au pixel.
* Ajoutez un taux d'ombrage par triangle.
* Utilisez la carte de l'espace écran, sauf si un taux plus grossier est spécifié. Il s'agit d'un excellent paramètre de combinateur par défaut.
* Lancer de rayons.
* Utilisez la même mesure de fréquence d'ombrage (la carte) pour contrôler le nombre de rayons.
* Diffusez le résultat du rayon aux pixels adjacents (lancer de rayons clairsemé).
## Conclusion
VRS est une optimisation puissante pour les PC et les appareils XBOX Series X|S.
* VRS offre une couverture parfaite et un contrôle local du taux d'ombrage. Il s'agit d'améliorations majeures par rapport aux fonctionnalités existantes.
* Il est facile d'intégrer VRS dans votre moteur. VRS s'intègre bien aux technologies existantes comme DRS et la mise à l'échelle temporelle.
* Les gains les plus importants de VRS sont obtenus lors du traitement d'effets traditionnellement coûteux, comme les flous, les ombres et les effets volumétriques.
* VRS présente une surcharge très faible.
Exploitez le signal VRS à l'aide de l'éclairage clairsemé.
* L'éclairage de données de g-buffer en double gaspille des ressources.
* D'autres passes clairsemées sont possibles.
* Réutilisez le nombre d'opérations d'éclairage nécessaires par tuile d'écran ainsi que leurs coordonnées.
Les exemples ATG fournissent un shader autonome pour calculer le taux d'ombrage. Pour plus d'informations sur VRS, consultez l'exemple VRSandSparseLighting dans les [exemples pour console du Microsoft GDK](https://learn.microsoft.com/gaming/gdk/docs/gdk-dev/development-downloads/gdk-samples-list#graphics).
## Étapes suivantes
Si vous souhaitez consulter les informations des supports de présentation liés à cette vue d'ensemble, téléchargez les fichiers suivants à partir de [XBOX Developer Download Secure Data Storage (SDS)](https://www.microsoft.com/en-us/software-download/gdk).
* Diaporama : XF2019\_Graphics\_08\_Day2\_Variable\_Rate\_Shading\_and\_Sparse\_Lighting.pptx dans Xfest 2019 Graphics Track PowerPoints (\[2019.11]-Xfest2019GraphicsTrackPowerPoints.ZIP)
* Présentation vidéo : XF2019\_Graphics\_08\_Day2\_Variable\_Rate\_Shading\_and\_Sparse\_Lighting.mp4 dans Xfest 2019 Graphics Track Videos (\[2019.11]-Xfest2019GraphicsTrackVideos.ZIP)
### Télécharger les présentations Microsoft PowerPoint et les vidéos
1. Accédez à [Téléchargements du Game Development Kit (GDK)](https://www.microsoft.com/en-us/software-download/gdk).
2. Sous Select file type, sélectionnez **Conference Materials**, puis **Confirm**.
3. Sous Select build/version number, choisissez l'une des présentations graphiques suivantes.
* Xfest 2019 Graphics Track PowerPoints
* Xfest 2019 Graphics Track Videos
4. Sélectionnez Download Now, puis attendez la fin du téléchargement du fichier .zip.
5. Accédez à votre dossier Téléchargements local, puis décompressez (extrayez) les fichiers du dossier compressé.
### Télécharger les exemples pour console du GDK mentionnés dans cette rubrique
1. Accédez à [Téléchargements du Game Development Kit (GDK)](https://www.microsoft.com/en-us/software-download/gdk).
2. Sous Select file type, sélectionnez **GDK**, puis **Confirm**.
3. Sous Select build/version number, choisissez l'option **Microsoft GDKX (Sample only)** la plus récente.
4. Sélectionnez Download Now, puis attendez la fin du téléchargement du fichier .zip.
5. Accédez à votre dossier Téléchargements local, puis décompressez (extrayez) les fichiers du dossier compressé.
6. Sélectionnez **GDKSamples** > **Graphics**. Recherchez l'exemple.
## Voir aussi
[DirectX 12 Specs - Variable Rate Shading](https://microsoft.github.io/DirectX-Specs/d3d/VariableRateShading.html)
[Variable Rate Shading](https://github.com/microsoft/DirectX-Specs/blob/master/d3d/VariableRateShading.md)
[Vue d'ensemble de l'ombrage à taux variable](/fr/build/core-features/graphics/newfeatures/vrs/vrs-overview)
[Pourquoi l'ombrage à taux variable ?](/fr/build/core-features/graphics/newfeatures/vrs/why-vrs)
[Conception de la fonctionnalité d'ombrage à taux variable](/fr/build/core-features/graphics/newfeatures/vrs/vrs-feature)
[AMD FidelityFX Variable Shading](https://gpuopen.com/fidelityfx-variable-shading/)
[Variable Rate Shading Update XBOX Series Consoles](https://www.youtube.com/watch?v=pPyN9r5QNbs)
[Variable Rate Compute Shaders - Halving Deferred Lighting Time](https://www.youtube.com/watch?v=Sswuj7BFjGo)
## Related topics
- [Exemples du GDK](/fr-CA/home/setup-install/samples.md)
- [Répertoire des rubriques NDA : liens actifs vers Microsoft Learn](/fr-CA/nda/nda-topic-directory.md)
- [Exemples GDK](/fr/home/setup-install/samples.md)
- [Intégration des partenaires XBOX : accès et publication](/fr/home/onboarding.md)
- [PFVariable](/services/playfab/api-references/c/pftypes/structs/pfvariable.md)