Conclusion

Maintenant que nous avons fait ce rappel technique, intéressons nous à l’origine du débat : 3DMark05 utilise les DST et le PCF, mais jusqu’ici ça a l’air d’être plutôt une bonne chose non ? Oui sauf que tous les fabricants ne supportent pas ces fonctionnalités.

En l’occurrence pour l’instant nVidia est le seul à les supporter. Pour être exact ATI supporte les DST, mais elles ne constituent pas une render target valide, autrement dit il est impossible d’effectuer un rendu directement dans une texture à ce format. Il faut donc faire un rendu dans le frame buffer puis le copier dans une texture ce qui s’avère extrêmement coûteux (même si la copie est locale). Pour pallier à ce problème, une solution consiste à effectuer le rendu dans une texture flottante ce qui évite cette copie, et c’est la solution choisie par Futuremark. Pour le PCF là encore, à part l’implémenter « à la main » en échantillonnant plusieurs fois la texture de profondeur et en effectuant la comparaison pour chaque échantillon puis en mélangeant les résultats (ce qui allonge d’autant le shader), il n’y a pas de solution directe.

Nous avons donc d’un côté ATI qui proteste que le benchmark n’est pas équitable lorsque les DST et le PCF sont activés vu que ses cartes effectuent plus de calculs que celles de son concurrent. Et de l’autre nVidia et Futuremark qui se justifient en argumentant que tous les jeux utilisant les Shadow maps utiliseront les DST et le PCF s’ils sont disponibles, avec le même type de solution de rechange que celle choisie par Futuremark dans le cas contraire. Par conséquent la comparaison donne une idée de la façon dont les cartes se comporteront dans les jeux utilisant les Shadow Maps.

Alors que peut on conclure au final ? Et bien si la solution DST+PCF se justifie pleinement dans le cas d’un jeu, dans un benchmark c’est plus discutable. En effet le rôle d’un benchmark est de fournir un outil permettant de mesurer les performances de cartes à charge identique (même si c’est fondamentalement impossible, disons à charge la plus proche possible). Or avec cette solution, force est de constater que ce n’est pas le cas. Rappelons nous du test advanced pixel shader de 3DMark 2001 : celui-ci utilisait les Pixel Shaders 1.4 sur R200 et était rendu en une seule passe alors qu’il utilisait les Pixel Shader 1.1 et était rendu en plusieurs passes sur NV20. Les résultats de ce test n’étaient pas pris en compte dans le score final car la charge n’était pas identique entre les cartes. Or ici la situation est exactement la même.

Pour être complet précisons que Futuremark offre la possibilité de désactiver l’utilisation des DST afin d’obtenir une charge comparable sur les différentes cartes. On peut toutefois regretter que ce ne soit pas le comportement par défaut et que ce ne soit pas faisable dans la version de démo.

On observe donc une divergence entre d’une part Futuremark qui positionne de plus en plus son benchmark comme représentatif des (futurs) jeux et le conçoit donc sur le même modèle : en utilisant plusieurs code path optimisés au mieux pour chaque carte, et les testeurs qui souhaitent un outil leur permettant d’isoler une partie spécifique du pipeline 3D et par conséquent se détournent de plus en plus de 3DMark.

Avant de conclure cet article, pour la petite histoire sachez que John Carmack a commencé les travaux préliminaires sur son prochain moteur et qu’il a abandonné les volumes d’ombre au profit des Shadow Maps. En ce qui concerne le filtrage utilisé, la version basse qualité utilise le filtrage PCF mais il a jugé que les résultats obtenus n’étaient pas satisfaisant lorsque ce filtrage était utilisé seul, et a donc décidé de le coupler à un filtrage effectué dans le fragment shader utilisant plus ou moins d’échantillons pour les modes haute qualité.