Tests jeux
Jedi Knight II
Basé sur l’inévitable moteur de Quake III Arena,
Jedi Knight II est pourtant bien plus chargé que le jeu originel
d’ID Software, ce qui en fait le jeu le plus intéressant
pour représenter les nombreux jeux basés sur cet excellent
moteur OpenGL codé par Carmack. Evidemment, très peu de
nouveaux jeux sont amenés à sortir sur ce moteur commençant
tout doucement à vieillir, mais sa présence se trouve évidemment
justifié par le succès que rencontrent toujours en réseau
les FPS basés sur ce moteur !
Notez qu’à part sur la Ti 4600, ce vieux moteur a été
tellement optimisé (en partie grâce au drivers) que c’est
le processeur qui limite le framerate malgré des résolutions
aussi conséquentes que pour les autres jeux ! Avec la GeForce FX,
le framerate le plus bas observé ne descend pas en-dessous de 62,
contre 47 pour la GeForce 4 en 1280*1024 AA + Aniso. Si vous ne jouez
qu’à des jeux basés sur ce moteur, aucun intérêt
d’upgrader si vous possédez déjà une GeForce
4 et un écran 19".
Serious Sam 2
Bon, je ne ferai pas l’affront de comparer le moteur des croates
de Croteam avec la puissance du moteur de Quake 3, mais ce moteur reste
intéressant dans la mesure où il est excessivement paramétrable,
utilise des textures de haute qualité, et reste plébiscité
par un certain public même s’il est clair qu’il se destine
plus, aujourd’hui, à des configurations modestes comparé
aux moteurs les plus récents.
Les tests ont été réalisés en mode OpenGL,
bien plus performant qu’en Direct3D. Par ailleurs, toutes les valeurs
du filtrage anisotropique ont été fixées manuellement
à chaque fois, car en sélectionnant le mode qualité,
le jeu modifie la qualité (et donc les performances) de l’anisotropie
appliquée en fonction de la carte détectée.
La GeForce FX s’exprime bien, 2x plus puissante qu’une Ti
4600 avec les filtrages activés. La Radeon 9700 parvient tout juste
a tenir la comparaison avec la GeForce 4…
Unreal Tournament 2003
Développé par Epic, le ‘Unreal Warfare’ qui
est le moteur 3D chargé d’afficher les scènes d’Unreal
Tournament 2003, est le moteur le plus gourmand de tous les FPS les plus
répandus actuellement. Permettant d’afficher des détails
assez extraordinaires et constituant le moteur à la base de nombreux
jeux à venir ou déjà sortis dont les plus connus seront
sans doute Deus Ex 2, Unreal 2, Rainbow six : Raven Shield, Splinter Cell,
The Y project ou encore Mobiles Forces, cela en fait un indicateur de
tout premier choix pour avoir une idée de l’abilité
qu’auront chacune de ces cartes 3D à calculer les scènes
des prochains jeux vidéo.
Reste qu’en l’état actuel, ce moteur est essentiellement
DirectX 7, utilisant le Transformation, Clipping and Lighting. Certains
shaders de DirectX 8 semblent être utilisés si disponibles,
mais leur importance est minime.
Dans le mode FLyby, aucun bot n’intervient, et ce mode est donc
plus dépendant de la carte graphique, tout en étant représentatif
d’une utilisation en mode Multijoueur de ce jeu.
Grosses performances de la GeForce FX ici, ce qui est logique vu la puissance
géométrique de ce GPU, et le fait que ce jeu n’a pratiquement
pas recours aux shaders. Mais le plus impressionnant est sans doute la
faible perte de performance entre le 1600x1200 et le 1280x1024 AA + Aniso,
car même avec de meilleurs algorithmes pour ces deux derniers effets,
la Radeon 9700 perd 35 % au change, contre 12 % pour la FX.
IL-2 Sturmovik
Traditionnellement, les simulations aériennes sont peu présentes
dans les protocoles de test, à l’exception peut-être
de Comanche 4. Pourtant, ce type de « jeu » fait partie des
plus gourmands en ressources, et la croyance selon laquelle c’est
le CPU qui influe majoritairement sur leurs performances reste à
démontrer avec les jeux réellement optimisés, à
l’inverse de Comanche 4 donc.
Fruit du travail de l’équipe d’Oleg Maddox, IL-2 Sturmovik
est le cobaye parfait pour déterminer l’importance du moteur
3D sur la fluidité du jeu, par rapport aux autres moteurs gérés,
notamment le moteur physique très lourd. Par ailleurs, la sortie
proche de IL-2 : Forgotten Battles, basé sur le même moteur,
achève de démontrer l’importance du comportement de
ce moteur pour le futur. Notez que les mêmes options ont étés
sélectionnées pour chaque API, même si visiblement
le jeu est plus à l’aise en mode OpenGL, d’abord en
terme de performances, et ensuite au niveau du rendu de certaines couleurs.
Premier constat : la GeForce FX semble plus à l’aise en
Direct3D qu’en OpenGL sur ce jeu. Tout comme la GeForce 4, mais
au contraire de la Radeon, même si je n’ai pu obtenir de chiffres
précis suite au plantage de Fraps. Ensuite, même sur ce type
de jeu, le passage de la GeForce 4 au GeForce FX / Radeon 9700 permet
un gros gain de performance. Enfin, la Radon 9700 rivalise sans problème
avec la FX Ultra sur ce test.
CodeCult
Affichant jusqu’à 842 000 polygones par frame dans les scènes
les plus lourdes (et au minimum 250 000), le benchmark de l’équipe
de CodeCreatures (développeurs allemands travaillant sous l’égide
de Phenomenia) est sans doute un des plus lourd actuellement, et ne sera
utilisé que dans les jeux à venir.
Pour donner un ordre de grandeur sur les polygones, sachez par exemple
que les models de Quake III sont composés d’environ 900 polygones
pour un modèle standard. John Carmack annonce entre 2000 et 6000
polygones pour les modèles de Doom 3, même si une grande
partie de leur réalisme sera due au bump-mapping qui leur sera
appliqué. A titre indicatif, sachez qu’un personnage d’une
animation précalculée est souvent composé de plus
de 200 000 polygones…
Utilisant également massivement les vertex et pixel shaders (version
1.0, 1.3 ou 1.4 en fonction de la version supportée par la carte),
Codecult reste néanmoins un benchmark DirectX 8.1.
Suite au plantage de la R9700 sous ce jeu, on peut simplement dire que
le gain de la GeForce FX par rapport à la GeForce 4 reste modeste
en comparaison du surplus de puissance, dans un test aussi gourmand.
Aquamark (V 2.3)
Dérivé du jeu Aquanox, et malgré quelques bugs d’affichage
dans cette version, ce benchmark reste intéressant car il est basé
sur un vrai jeu qui utilise massivement les Pixel Shaders de DirectX 8.1
(Krass Engine). Cela dit, le nombre de polygones maximum par frame ne
dépasse pas 180 000, à comparer aux 780 000 de la scène
‘Mother Nature’ de 3DMark03. La sortie d’Aquamark 3,
basée sur DirectX 9 est d’ailleurs imminente.
Ici, les choses semblent rentrer dans l’ordre en ce qui concerne
la FX. On notera particulièrement la mauvaise tenue de la Radeon
9700 qui se fait battre en 1600x1200 par une « simple » GeForce
4.
SPECViewPerf 7.0
SPECViewPerf 7.0 est un benchmark basé sur des applications professionnelles
OpenGL (3DS MAX 3.1, Lightscape, Intergraph DesignRevew, Pro Engineer
2000, Unigraphics V17 et IBM Data Explorer). Bien sûr, là
vous vous demandez quel est l’intérêt d’inclure
un benchmark testant des applications professionnelles, sur des cartes
avant tout destinées aux joueurs ? La réponse est simple
: le joueur qui paiera jusqu’à 600 € sa carte n’a-t’il
pas le droit de s’essayer à des logiciels tel 3D Studio Max
et de bénéficier de performances décentes ? Evidemment,
les drivers de ces cartes ne sont pas optimisés en ce sens, car
nos protagonistes disposent tous deux d’autres cartes orientées
vers ce marché et basées sur les mêmes GPU ; cela
dit l’indice reste intéressant, en attendant d’éventuelles
modifications hardware pour faire reconnaître sa GeForce FX 5800
comme une Quadro FX 2000…
Notez par ailleurs que Standard Performance Evaluation Corporation a
le mérite de manifester une réelle volonté de faire
en sorte que les tricheries via les drivers soient très difficiles,
notamment par la nature des tests et les mises à jours très
régulières. Ce qui est un moyen autrement plus élégant
que le bannissement pur et simple des drivers incriminés, même
si dans ce cas Futuremark était dans son plein droit.
Ce que teste SPECViewPerf 7.0 (vous trouverez plus d’informations
sur chaque test directement sur le site) :
• 3D primitives, including points, lines, line_strip, line_loop,
triangles, triangle_strip, triangle_fan, quads and polygons;
• attributes per vertex, per primitive and per frame;
• lighting;
• texture mapping;
• alpha blending;
• fogging;
• anti-aliasing;
• depth buffering.
Que dire… la contre performance de la R9700 est énorme !
Certes, seul nVidia a une réelle présence auprès
des développeurs, mais ces résultats surprenants ont été
obtenus plusieurs fois. Ils vont à l’encontre des résultats
obtenus par d’autres sites. Dans tous les cas la GeForce 4 se comporte
extrêmement bien face aux deux ténors près de 3 fois
plus chers qui lui sont opposés…
Influence de la fréquence de la mémoire
par rapport au GPU
Enfin, j’ai voulu réaliser un petit test pour mettre en avant
l’importance relative de la fréquence de la mémoire
par rapport à la fréquence du GPU, sur 2 chips ayant une
génération de différence.
Ce test prouve une évolution à mon avis essentielle, dont
le GeForce FX sera le point de pivot. Auparavant, du fait de l’utilisation
de scènes 3D peu complexes sur des résolutions déjà
élevées, il était avéré que la fréquence
de la mémoire embarquée sur les cartes graphiques était
le principal goulot d’étranglement pour les performances,
notamment dans les conditions "extrêmes".
De manière indéniable ici, nous voyons qu’avec l’architecture
de la GeForce FX, la fréquence du GPU revêt plus d’importance
que la fréquence de la mémoire. Alors que pour la GeForce
4, c’est l’inverse. Cela signifie simplement qu’avec
les nouvelles générations de GPU, et avec la généralisation
des shaders, les GPU ne passent plus leur temps à attendre les
données comme c’était le cas auparavant, et que peu
de données sont nécessaires pour l’exécution
de gros calculs.
Considérons par exemple le Trueform. Précédemment,
il était nécessaire de faire passer, de la mémoire
centrale au GPU, un objet formé de 100 polygones (par exemple)
pour afficher l’objet final. En utilisant le Trueform, il n’est
plus nécessaire que de faire passer une forme géométrique
composé de 30 polygones (pour schématiser), puisque ce sera
désormais au CPU d’interpoler des détails supplémentaires
sur l’objet considéré.
Donc, dans le premier cas, le GPU se contente d’afficher et les
échanges mémoires sont lourds ; dans le second, le flux
d’information qui transite jusqu’au GPU est beaucoup plus
faible, mais en contrepartie le GPU à toute une phase de calculs
à effectuer. Voilà pourquoi il est raisonnable de penser
que ce sera désormais le GPU qui constituera le principal goulot
d’étranglement dans les prochaines cartes 3D.