Présentation (suite)

Test CPU

A l’instar des versions précédentes, le test CPU de 3DMark05 exécute les tests « jeux » en basse résolution avec des vertex shaders software (donc calculés via le CPU) et en désactivant les effets ‘post-process’. Cela permet de réduire la charge graphique et de produire un résultat représentant principalement les capacités du CPU à rendre une scène 3D et exécuter d’autres tâches de jeux 3D comme des calculs de matrices. Par contre, 3DMark05 introduit également le calcul du chemin utilisé par le vaisseau volant. Celui-ci suit cependant toujours le même chemin à chaque fois afin de représenter des calculs comparables, mais ces calculs sont néanmoins réalisés à chaque fois afin de prendre en compte la forme du canyon et les obstacles comme le monstre marin. En d’autres termes, ce test CPU inclus donc les algorithmes d’intelligence artificielle propres au pathfinder des jeux (en solo uniquement, puisqu’à priori cet algorithme n’est utilisé que par les personnages contrôlés par l’ordinateur).

Point important à noter, les calculs de ce pathfinder sont implémentés dans un thread différent de celui du rendu. Le but consiste bien sûr à favoriser les système à 2 (et pas plus) processeurs logiques ou physiques, ce qui constitue clairement l’orientation de l'industrie du CPU.

Le second test CPU exécute le test ‘Return to Proxycon’ en 640x480 avec un framerate fixé à 2 images/seconde, les vertex shaders en mode software et les effets ‘post-process’ désactivés. Comme pour le premier test CPU en somme, sauf que les calculs d’IA sont ici évincés.

Le score du test CPU est quand à lui obtenu d’une manière assez similaire au score global :

• CPU score = (CPU Test 1 * CPU Test 2)^0.5 * 1500

Même si ce n’est pas le but de cette section, on peut dès à présent se questionner sur l’intérêt d’effectuer et de prendre en compte ces deux tests pour le score CPU. La seule différence entre les deux tests est la présence ou non des calculs de l’algorithme de pathfinder. Ceci semble toutefois avoir été fait dans le but de ne pas trop pénaliser les systèmes mono-processeurs, puisque évidemment le second test CPU ne tire pas directement parti de l’Hyperthreading, du bi-core ou du bi-CPU. Reste à savoir si ces processeurs auront réellement tant d’importance que cela d’ici deux ans dans les performances des jeux vidéo…

Feature tests

Ici, nous retrouvons les nouvelles versions des tests synthétiques présents dans les précédents opus.

Fillrate

Sur ce classique, Futuremark a légèrement changé sa méthode et opère désormais un test plus théorique, qui permet d’être plus indépendant de la bande passante. En effet, les précédents tests de fillrate étaient plus ou moins limités par la bande passante, un comble pour un test qui n’a pourtant rien à voir avec la mémoire. En fait le problème venait du fait que Futuremark considérait auparavant ce test comme étant aussi une indication des performances sur les jeux limités par le fillrate, et donc également assez dépendants de la mémoire via le chargement de grosses textures. Du coup, le test utilise désormais des textures plus petites, et est donc moins joli (peut-être était-ce aussi cela le vrai problème : privilégier l’esthétisme à l’efficacité ?).

En single texturing, 64 quads de la taille de l’écran sont texturés avec une texture de 2x2 (résolution plus basse que dans 3DMark03 donc). Ce test utilise le path fixed fuction (T&L). En multi texturing, on descend à 8 quads et on monte à 8 textures de 2x2.

Pixel Shader

Ce test extrait en fait le shader de surface du canyon du Test 3. Une source lumineuse se déplace sur le relief rocheux, mais sans ombres en temps réel, simplement avec l’éclairage des vertices.

Ce test est également dépendant de la bande passante, sous prétexte qu’un jeu avec des shaders complexes effectuera de nombreux recours à de grosses textures. L’alternative aurait consistée à utiliser le ‘procedural texturing’, mais Futuremark n’a pas fait ce choix. D’abord parce qu’ils l’avaient déjà fait dans 3DMark03. Ensuite parce qu’il semblerait que les jeux ne s’orientent pas vers les textures procédurales dans ce genre de situation.

Vertex Shader

Deux tests sont présents pour évaluer les capacités en vertex shaders.

Le test simple effectue une transformation et un éclairage simple sur 4 têtes de monstres marins modélisées avec beaucoup de polygones. Chaque tête possède plus de 1 million de vertices qu’il faut illuminer et déplacer. Le shader utilisé ici pourrait très bien n’avoir recours qu’au Shader Model 1 de DirectX 8.0, mais 3DMark05 se concentrant sur DirectX 9.0, ce shader est déclaré via le HLSL en Shdader Model 2 comme tous les shaders utilisés dans les tests « jeux ».

Le second test se concentre quand a lui sur une quantité importante de brins d’herbe. Chaque brin est mis en mouvement séparément, en accentuant l’effet au niveau de l’extrémité supérieure (comme les vrais brins d’herbes se couchent au passage du vent). Les brins se couchent suivant un bruit fractal calculé par le CPU mais optimisé de manière à réduire l’influence de ce dernier sur les performances. L’herbe est assez distante de la caméra de manière à réduire l’influence du fillrate, au détriment de l’esthétisme de la scène.

Batch Size Tests

3DMark05 introduit tout de même un nouveau type de ‘Feature tests’. Celui-ci consiste à effectuer le rendu d’une scène très simple et non optimisée, dans le but de mesurer un point faible de la plupart des drivers de cartes 3D. Les constructeurs de GPU ont depuis toujours poussés les développeurs de jeux à effectuer le rendu de lots les plus grands possibles. Il serait cependant bénéfique d’optimiser également le rendu de lots plus petits. Ce test, demandé par plusieurs membres du programme de développement, consiste à dessiner 128 quads de 128x128 pixels avec 8, 32, 128, 512 2048 puis 32768 triangles par lot. Si l’on peut considérer qu’un lot de 32768 triangles ou même 2048 triangles est suffisamment grand pour être optimisé par la plupart des drivers actuels, le rendu devient plus lent en réduisant la taille du lot. Différents changements de couleurs sont effectués afin d’être sûr que DirectX ne rassemblera par le rendu en seulement quelques lots comme c’était le cas initialement sur ce test.

Benchmark Settings

Signalons ici que 3DMark05 supporte de nouveaux paramètres afin d’évaluer différentes parties des cartes 3D. Il est ainsi possible de spécifier le profil HLSL utilisé pour chaque pixel shader (2_0, 2_a, 2_b, 3_0) et vertex shader (2_0, 2_a, 3_0) de chaque test, du moins pour les cartes les supportant. A noter cependant que l’activation des PS 3.0 provoque obligatoirement l’activation du VS 3.0 et vice versa.

Attention, par défaut 3DMark05 détecte le DirectX Caps afin de présélectionner le profil le plus optimisé pour la carte 3D du système. Ainsi, les paramètre par défaut ne sont donc pas équitables sur toutes les cartes (phénomène amplifié via la présélection du filtrage de texture optimal, lui aussi variable suivant les cartes).

Concernant les options de désactivation, il est possible de forcer la meilleure précision (suivant le cas, 24 bits ou 32 bits) mais également de désactiver le DST (‘Depth-Stencil Texture’). Activé par défaut sur les cartes le supportant (soit les cartes nVidia, et ce depuis longtemps, à l'inverse des cartes ATI), il s’agit d’une fonctionnalité câblée en hardware qui permet par exemple d’optimiser le rendu des ombres dynamiques. Il est également possible de forcer un rendu intemporel, comme expliqué dans notre test de 3DMark03.

Outils

Enfin, on note la présence et l’amélioration des deux outils existants permettant de contrôler la qualité du rendu. D’abord, l’outil de qualité d’image, qui permet pour rappel d’effectuer le rendu d’une image donnée pour un test donné, et de la comparer au rendu par défaut (‘Reference Rasterizer’) si le SDK de DirectX 9 est installé. La nouveauté principale est qu’il est possible d’effectuer le rendu d’une séquence (fixée à 30 fps), et d’alterner le rendu des images sur deux systèmes.

On retrouve également le tunnel de filtrage des textures, qui se dote en sus des fonctions d’antialiasing. Honnêtement, l’idée de regrouper ces deux effets sur une seule scène type est assez moyenne, car si l’utilisation d’un tunnel est assez pertinente pour remarquer les problèmes de filtrage de texture, c’est moins le cas pour les effets d’escaliers par rapport à ce que d’autres outils permettent. Nous y reviendrons plus loin.

Au niveau des détails, on notera que 3DMark05 utilise au niveau de la compression des textures le DXT1 pour les ‘color maps’, le DXT3 pour les ‘alpha maps’, et enfin le DXT5 pour les ‘normal maps’. Pas d’utilisation du 3Dc d’ATI donc ! Cela peut se comprendre dans la mesure où ATI est le seul constructeur à mettre en avant cette fonctionnalité. Pourtant, nVidia est également le seul constructeur à vendre des puces supportant le SM 3.0, pourtant présent dans 3DMark05. Certes, le SM 3.0 est un standard définit dès DirectX 9.0 et il est certain que les prochaines puces graphiques de tous les constructeurs le supporteront. Mais cela veut dire aussi que Futuremark ne croit pas en l’utilisation du 3Dc dans les prochains jeux, ce qui reste à vérifier vu sa simplicité d’implémentation.

Globalement, 3DMark05 peut donc être considéré comme une mise à jour de 3DMark03 se concentrant uniquement sur les fonctionnalités de DirectX 9.0.