Lors de l’implémentation de la technique de rendu en damier (CBR), l’essentiel de l’effort consiste à modifier soigneusement vos pixel shaders. Depuis la version XDK QFE2 de juin 2017, nous fournissons une fonctionnalité de compilateur permettant de modifier automatiquement vos shaders pour prendre en charge le CBR. Cela vous permet d’adopter rapidement le CBR, tout en facilitant le retour en arrière. Il est également possible de désactiver ces modifications au runtime sans recompiler vos shaders, mais cela nuit aux performances et ne doit être utilisé que pendant le développement.
Plusieurs configurations MSAA peuvent être utilisées avec le CBR : les dispositions « carrée » 4xMSAA ou « rectangulaire » 2xMSAA. Nous avons supposé que vous utiliserez la disposition rectangulaire horizontale. Les cibles de rendu doivent être deux fois moins larges que les cibles de rendu sans CBR, mais avec deux échantillons par pixel. Nous supposons que vous utiliserez l’EQAA 1f2s pour réduire le stockage des couleurs.
Cette fonctionnalité du compilateur n’introduit pas de fonctionnalité « Triangle ID » dans vos shaders. Aucune stratégie n’est non plus appliquée pour le test alpha, qui nécessite de tester tous les échantillons. Pour plus d’informations, consultez l’autre livre blanc sur le CBR, Rendu en damier sur XBOX One.
Le CBR consiste à rendre la moitié des pixels sur les images paires et l’autre moitié sur les images impaires, en alternance. Pour obtenir cet effet, le MSAA est utilisé de manière non conventionnelle. Pour réduire l’ombrage de moitié, les pixels sont associés par paires sous forme de 2xMSAA. La disposition d’échantillons par défaut n’est pas une grille régulière ; nous réaffectons donc les positions des échantillons au centre des moitiés gauche et droite du pixel. Nous activons l’ombrage par échantillon afin que chaque échantillon soit ombré à sa position (c’est-à-dire que les attributs de vertex sont interpolés à la position de l’échantillon). Nous limitons ensuite l’itération d’échantillons du shader à un (‘0’ en unités log2) afin que seul le premier échantillon soit ombré.Les positions des échantillons peuvent être programmées indépendamment pour chaque coin du quad de pixels. Nous utilisons cela pour former un motif en damier alterné. Par convention, nous recommandons que les images paires rendent le pixel à (0, 0). En pseudo-code, voici comment nous affectons les positions des échantillons 0 et 1.
Comme les échantillons sont décalés et inclinés, les gradients des coordonnées de texture sont déformés. Les gradients doivent être corrigés différemment selon que l’image est paire ou impaire. La formule est la suivante :
Comme les gradients doivent être corrigés, tout échantillonnage de texture qui utilise des gradients, implicitement ou explicitement, doit être remplacé par des instructions d’échantillonnage explicites basées sur les gradients et utiliser les gradients corrigés. Voici la liste des méthodes HLSL concernées :
Sample() SampleBias() SampleCmp() ddx*() ddy*()
Les méthodes non concernées sont les suivantes :
SampleGrad() (note that the gradients may be affected) SampleLevel() SampleCmpLevelZero() Gather*()
Le compilateur peut également, de manière facultative, doubler automatiquement la valeur de SV_Position.x. Comme les fenêtres d’affichage CBR sont deux fois moins larges, SV_Position.x a une plage deux fois plus petite que pour le rendu sans CBR. Certaines lectures de textures dans l’espace écran peuvent devoir être relatives aux dimensions complètes de la fenêtre d’affichage. Si vous avez besoin que les coordonnées dans l’espace écran soient cohérentes avec les coordonnées sans CBR, une option permet de doubler automatiquement SV_Position.x
Pour demander au compilateur de shaders d’activer le damier automatique, définissez cette macro. Cette macro détermine également le constant buffer et l’offset où vous fournirez le bit « FrameIsOdd ».
Indique que le CBR doit être activé automatiquement et que le bit de parité se trouve dans le constant buffer lié au registre register(b1, space20), avec un offset de 28 octets (7 * 4 octets). (Dans la version actuelle de cette fonctionnalité, il doit s’agir d’un CBV racine, c’est-à-dire qu’il ne doit pas se trouver dans un tas de descripteurs et ne doit pas être une constante racine.) Le bit est toujours le LSB du quadword. Notez que l’espace de noms est facultatif. S’il est omis, il prend par défaut la valeur space0, ce qui est conforme au Shader Model 5.0.
Pour activer le doublement automatique de SV_Position.x afin d’assurer la cohérence avec le rendu sans CBR, définissez :
Pour pouvoir activer ou désactiver le mode CBR sans recompiler les shaders, vous devez également définir :
#define __XBOX_AUTO_CBR_DYNAMIC_MODE
Cette directive augmente la complexité des shaders, car les modifications doivent tester un autre bit pour déterminer s’il faut utiliser les gradients corrigés ou d’origine, et s’il faut mettre à l’échelle SV_Position.x. Ce bit est adjacent au LSB. Une valeur ‘1’ indique que le CBR doit être désactivé.
L’activation du CBR dans un shader a un coût en performances, sous la forme d’instructions supplémentaires, d’une utilisation accrue des registres et de lectures de textures SampleGrad plus coûteuses. Mais n’oubliez pas que vous utiliserez environ deux fois moins de threads de pixel shader. Pour un calcul approximatif, supposons un surcoût de 10 % lié à l’ajout de la prise en charge du CBR à votre shader. Avec un coût de 110 % multiplié par 50 % des threads, nous devrions nous attendre à environ 55 % du temps d’exécution total pour les seuls pixel shaders. Cependant, le travail des vertex shaders n’est pas affecté, et la quantité de mémoire de texture lue ne devrait pas l’être non plus. Nous avons observé des temps de rendu CBR d’environ 60 % de ceux du rendu sans CBR (pour les passes de rendu concernées), ce qui semble conforme aux attentes.Avec la prise en charge du mode dynamique, portons l’estimation du surcoût à environ 12 %, ce qui est mineur mais indésirable dans un titre commercialisé. Cela porterait les passes CBR à 61 % du rendu sans CBR. Mais si vous utilisez le même shader pour le rendu sans CBR (en définissant le bit de « désactivation »), vous pouvez vous attendre à ce que vos passes d’ombrage atteignent 112 %, ce qui est difficile à accepter. Nous ne recommandons pas de commercialiser un jeu avec des shaders compilés avec __XBOX_AUTO_CBR_DYNAMIC_MODE. Toutefois, vous devez mesurer la différence dans votre jeu, car vos goulots d’étranglement peuvent être différents.En raison du surcoût lié aux calculs de gradients, nous vous conseillons de remplacer Sample() par SampleLevel() lorsque vous savez que la texture ne comporte pas de mipmaps. De même, pour SampleCmp() avec des shadow maps, vous devez utiliser SampleCmpLevelZero() à la place. Aucune des deux formes n’est incorrecte et elles produisent les mêmes résultats visuels, mais le compilateur ne sera plus contraint de corriger des gradients lorsque ceux-ci n’ont aucun effet.
Grâce à notre compilateur de shaders, vous pouvez implémenter plus facilement le CBR dans votre moteur de jeu. Nous facilitons également la coexistence de chemins de rendu avec et sans CBR, afin que vous puissiez comparer les performances et la qualité visuelle. Tout n’est pas fait à votre place, mais la partie sans doute la plus difficile peut être évitée grâce à quelques directives du compilateur de shaders. Vos shaders restent inchangés, ce qui préserve leur lisibilité et leur exactitude. Nous nous attendons à ce que les shaders compilés pour le CBR soient plus longs et un peu plus lents, mais en suivant les recommandations de ce document, vous pouvez éviter toute dégradation inutile des performances.
Last modified on October 6, 2026
Was this page helpful?
⌘I
Assistant
Responses are generated using AI and may contain mistakes.
