Tests CPU et synthétiques

Tests CPU : Red Valley

Ce test met en scène deux châteaux, séparés par un labyrinthe de canyons. 87 véhicules (speeders ou tanks) sont lâchés : les speeders tentent de rejoindre l’autre château, tout en évitant les collisions avec les autres speeders ainsi que les tanks qui tentent de les détruire.

Il essaye de représenter trois tâches parmi les plus gourmandes demandées aux CPU pendant l’exécution de jeux. En premier, l’exécution du jeu en elle-même, incluant le moteur 3D. Cette tâche est exécutée via un thread principal, qui dirige les deux autres. On y trouve la simulation physique, gérée via un autre thread distinct et chargé de simuler le monde et notamment le déplacement et les collisions des 87 véhicules, et ce toutes les 20 ms. La bibliothèque utilisée pour ce faire n’est autre que le PhysX d’AGEIA. N’oublions pas que le PPU ne va plus tarder à arriver maintenant… cela dit, Futuremark était obligé de faire un choix ici et celui du Havok n’aurait pas forcément été plus heureux.

La dernière tâche concerne le path finding, la seule véritable tâche d’IA en tant que telle. C’est celle qui consiste à déterminer quel chemin chaque unité doit utiliser pour rejoindre un point à un autre. Ce travail est scindé en un nombre variable de threads, suivant le nombre de processeurs disponibles, et est lui aussi synchronisé avec le thread principal (toutes les 200 à 600 ms). La complexité de chaque recherche de chemin varie assez grandement, car l’algorithme utilisé est dynamique et souvent capable de réutiliser le résultat des précédentes recherches. Il s’agit d’ailleurs du D* Lite.

Les deux tests CPU sont sensés être exécutés à un framerate fixe de 2 images/seconde (en pratique, comptez plusieurs secondes pour rendre une seule image sur un CPU single-thread !). La différence entre les deux tests CPU tient aux paramètre utilisés : le premier a un pathfinder plus complexe et des intervalles de synchronisation d’IA plus courts que le second, qui est plus long (60 images calculées au lieu de 40). Ainsi la charge physique représente 8 % de la charge totale du test 1, contre 13 % du test 2. Un test avant tout orienté multi-core donc.

Feature tests

Ne rentrant pas dans le calcul du score global, des tests synthétiques restent présents dans cette édition 2006. Si le test de Fillrate n’évolue pas, le test de Pixel Shader extrait toujours le shader de surface du Canyon du test 3.

Or comme celui-ci est passé au SM 3.0 dans 3DMark06, le test de Pixel Shader évolue donc également. Reste que de l’aveu même de Futuremark, ce test reste dépendant de la bande passante mémoire.

Les deux tests de Vertex Shader n’ont pour leur part pas bougés, et utilisent le Shader Model 2.0 bien que le résultat aurait pu être obtenu en se restreignant au Shader Model 1.0. De même pour le test de rendu de lots. En revanche, deux nouveaux tests sont introduits.

Le premier, Shader de particules, consiste à effectuer une tâche physique par la carte graphique : la chute de particules sur un corps, selon la loi de la gravitation.

Un pixel shader effectue cette simulation via un schéma d’intégration d’Euler afin de déterminer la trajectoire de 409600 particules, et nécessite le support du SM 3.0 avec le Vertex Texture Fetch. Un test dont on peut remettre en cause l’intérêt toutefois puisqu’il ne faut pas oublier que pendant que la carte 3D effectue cette tâche, elle dispose de bien moins de ressources à allouer au rendu 3D, seul le CPU bénéficiant de l’opération (permettant tout de même une vitesse d’exécution plus importante). La prise en charge des calculs physiques par le GPU tel qu’annoncé par Havok est intéressante, mais nous restons assez sceptiques en l’attente des premiers exemples concrets en matière de jeux, et hors solutions multi-GPU.

Le dernier test, Perlin Noise, est un autre test Shader Model 3.0 dans la mesure où il utilise un pixel shader de 495 instructions (dont environ 9 instructions arithmétiques pour 1 instruction de texturing). Pour rappel, le bruit de Perlin est un algorithme utilisé dans beaucoup de textures procédurales, et permet de générer des motifs en partie aléatoires, utilisés pour des éléments complexes comme les nuages. Il est donc peu gourmand en bande passante/mémoire, mais réclame beaucoup de puissance de calcul.