Performances CPU : Catalyst 14.7 RC3 vs GeForce 340.52

Publié le 16/09/2014 par
Imprimer

Suite à la mise en place de notre nouveau protocole de test processeur, nous avons voulu mesurer l'impact des pilotes graphiques dans nos tests jeux 3D qui sont principalement limités par la puissance CPU. En effet l'initiative Mantle d'AMD, suivie depuis par Microsoft avec un DirectX 12 prévu pour 2015, a mis en lumière le (sur)coût processeur des commandes de rendu sur les API actuelles, domaine dans lequel les pilotes peuvent avoir un impact.

Pour rappel, Mantle est une API de plus bas niveau annoncée l'an passé par AMD et qui permet de réduire le coût processeurs des commandes et de mieux tirer parti des processeurs à multiples cœurs, ce qui implique de transférer une partie significative de la responsabilité des performances vers le moteur de jeu.


En pratique le premier jeu à en bénéficier fut Battlefield 4, avec des gains impressionnants puisque pouvant atteindre 80% par rapport au jeu fonctionnant en Direct3D sur la même carte AMD lorsque les performances sont limitées par le CPU et non pas par le GPU ! Mais ce lancement avait également montré que le gain était environ deux fois moindre si l'on comparait aux performances Direct3D sur une carte Nvidia, preuve que le pilote des verts était mieux optimisé en D3D pour ce cas de figure.

Plus une API graphique est complexe, prend des chemins tortueux et accuse un surcoût ou overhead élevé, plus les fabricants de GPU ont d'opportunités de se démarquer de la concurrence via leurs pilotes. De plus, des optimisations qui sont cette fois destinées à optimiser le coût du GPU, tels que les remplacements de shaders, peuvent de leur côté alourdir la charge processeur liée au pilotes. Il existe des opportunités d'optimisation de l'usage CPU, même sous les API DirectX actuelles, elles ne sont pas nouvelles puisque fin 2008 nous avions déjà remarqué un avantage en faveur des pilotes Nvidia face aux pilotes AMD pour ce qui était des performances sur quatre cœur sous DirectX 10, souci sur lequel AMD avait réagi début 2009.

Depuis cet aspect n'avait pas été souvent observé, les tests de GPU s'orientant logiquement vers les mesures de puissance graphique et donc dans des cas où ce n'est pas le CPU qui limite le framerate final, plutôt que sur l'optimisation des pilotes vis-à-vis des processeurs. L'introduction de Mantle aura toutefois rappelé qu'il peut y avoir des différences importantes à ce niveau, et Nvidia avait d'ailleurs profité de la GDC 2014 pour annoncer des avancées supplémentaires dans ce domaine sur son pilote Direct3D qui ont été introduites dès le mois d'avril. Nous avions mesuré les écarts lors du test de la Radeon R9 295X2.

Notre nouveau protocole de test introduit avec les Haswell-E utilisant une GeForce GTX 780 Ti couplée aux pilotes 340.52, nous nous sommes dit que l'occasion était bonne pour comparer les pilotes Direct3D, mais aussi OpenGL dans le cas de X-Plane, AMD et Nvidia. Nous avons donc fait subir à deux processeurs, un AMD FX-8350 et un Core i5-4670K, les mêmes tests avec cette fois une Radeon R9 290X et les pilotes Catalyst 14.7 RC3.

Attention il ne s'agit donc pas d'une comparaison entre les GPU R9 290X et GTX 780 Ti, les performances étant dans tous les cas limitées ici par la puissance de traitement du CPU. Nous sommes dans des cas appelés "CPU limited", c’est-à-dire que la création de la scène 3D côté CPU met plus de temps que le rendu de la scène 3D côté GPU.

Dans ce cas les performances sont limitées par la première partie, puisque le GPU "attends" les informations lui permettant de rendre la scène. Pour schématiser, s’il faut 20ms (soit 1/50è de secondes) côté CPU et 10ms (soit 1/100è de secondes) côté GPU alors le framerate sera limité à 50 images/s du fait de la valeur la plus élevée, les deux temps ne s’accumulant heureusement pas puisque pendant le rendu GPU le CPU ne se tourne pas les pouces mais prépare l’image suivante.

CPU Limited ?

Vu les nombreux commentaires générés par cet article, cette notion de "CPU limited" semble être très floue pour une partie de notre lectorat, bien que nous l'ayons déjà abordée à de multiples reprises. Des explications sont donc nécessaires. Pour schématiser, la création de ce que vous voyez à l'écran dans un jeu peut être découpée en plusieurs grandes étapes.

Premièrement, le moteur du jeu s'occupe de maintenir en mémoire une représentation du monde dans lequel le joueur évolue, sous la forme de de coordonnées (pour la position) et de vecteurs (pour la direction/mouvements) et d'autres données diverses. Ce modèle évolue bien entendu en fonction des entrées du joueurs (clavier/souris) mais également des actions propres du jeu (intelligence artificielle) ou de tiers (adversaires via le réseau). Selon les jeux et les moteurs, cette représentation du monde (simulation) peut être plus ou moins complexe à maintenir et peut faire intervenir un ou plusieurs threads.

Cette simulation est utilisée par le thread de rendu qui va récupérer les informations afin de préparer les commandes qui devront être envoyées au GPU par l'intermédiaire de l'API et du pilote graphique. Cette préparation se fait historiquement de manière séquentielle (dans un seul thread) sous DirectX 9 et OpenGL et elle tend à être particulièrement coûteuse en temps processeur (nous vous renvoyons au débat des "Draw Calls" qui a vu les annonces successives d'API beaucoup plus optimisées comme Mantle chez AMD, DirectX 12 pour Microsoft, Metal chez Apple et même l'annonce d'un OpenGL-next pour tenter de compenser le problème). Il est a noter que le temps CPU dont on parle ne dépend pas que de l'application et de l'API : les pilotes sont également partie prenante à ce niveau. En effet si les appels vers l'API dans l'application sont séquentiels, il est possible pour le pilote graphique (avec plus ou moins de succès) d'essayer de paralléliser certaines des tâches liées à leur traitement. Indépendamment de sa capacité à paralléliser, la capacité du driver à traiter efficacement les commandes qui lui sont envoyées aura un impact sur la consommation processeur finale.

Le coût processeur de ces API peut tout de même être en partie compensé, à condition que les développeurs fassent quelques efforts. DirectX 11 par exemple à introduit les Deferred Context afin d'autoriser d'envoyer des commandes à partir de multiples threads. Un pas en avant, certes, mais qui n'est pas suffisant car limité et qui poussera Microsoft à reprendre entièrement le problème de zéro avec DX12 suite à l'initiative Mantle d'AMD. Notez que dans le cas des Deffered Context, la encore l'implémentation par le driver va jouer un rôle important sur les performances finales, chaque driver disposant d'optimisations spécifiques qui pourront plus ou moins bien marcher d'une application à l'autre. D'autres techniques existent notamment pour OpenGL comme le concept des mutualisation de draw calls, uber-shaders, bindless textures et autres optimisations, plus ou moins simples à implémenter mais qui peuvent avoir un impact. Si vous souhaitez plus d'informations sur ce sujet fort technique, nous vous renvoyons à l'excellente session « AZDO » (Approaching Zero Driver Overhead) de la GDC 2014 dont vous pouvez retrouver les slides ici .

Ces deux étapes (simulation, préparation du rendu) se font sans l'aide du GPU, il s'agit purement d'une charge côté CPU. Enfin les commandes nécessaires au rendu de l'image 3D sont envoyées au GPU qui va se charger de les traiter au travers de multiples étapes que nous avions décrites dans cet article pour ce qui est du rendu différé. La partie CPU, les deux premières étapes, et la partie GPU, la troisième, se font en parallèle, c'est-à-dire que pendant le rendu GPU le CPU ne se tourne pas les pouces mais continue de mettre à jour le modèle et à préparer les commandes qui seront à envoyer au GPU pour l'image suivante.

Lorsque votre PC arrive à faire tourner un jeu à 50 images/s, cela signifie qu'il y a un délai de 20ms séparant chaque nouvelle image. Il ne s'agit donc pas avec un rendu classique du temps cumulé de ces trois opérations, mais bien du temps maximal de l'une d'entre-elles. On est dans un cas dit "GPU limited" quand l'étape liée au GPU est exécutée plus lentement que l'étape CPU la plus rapide, et dans un cas "CPU limited" dans le cas inverse.

En pratique, voici quelques mesures effectuées sur notre scène de test de Crysis 3, très lourde côté processeur, illustrant ce qu'est un cas "CPU limited" comme tous les autres cas utilisés plus loin dans l'article. Les mesures sont effectuées sur un Haswell-E 8 cœurs à 3.5 GHz avec Uncore à 3.0 GHz et DDR4-2133 13-13-13.

Nous faisons varier le temps de traitement CPU en activant 4 ou 8 cœurs (l'Hyperthreading restant désactivé), il aurait également été possible de jouer sur la fréquence mais Crysis 3 étant bien multithreadé nous en profitons, ou encore de jouer sur des paramètres qui impacte principalement le CPU par rapport au GPU (distance de vue par exemple).

Le temps de traitement GPU varie grâce à plusieurs paramètres, puisque nous utilisons 3 cartes graphiques (GTX 680 de référence, R9 290X en mode "Uber" et MSI GTX 780 Ti Gaming OC) d'une part mais aussi 3 réglages différent en terme de résolution et d'anticrénelage, des paramètres qui impactent uniquement le GPU.



Ces résultats nous montrent qu'avec 4 cœurs, nous sommes systématiquement "CPU limited", sauf sur la GTX 680 en 1920*1080 MSAA 4x qui voit son score légèrement baisser par rapport aux résolutions précédentes. La limite processeur est aux alentours de 34 fps sur avec les Nvidia, et à 32 fps avec la 290X, l'avantage est donc à Nvidia et ses pilotes sur ce jeu.

Les tests avec 8 cœurs permettent de réduire le temps de traitement côté processeur, ce qui permet avec une charge GPU réduite (1280*720) d'atteindre 56 fps environ sur Nvidia et 49 fps sur AMD du fait de limite côté processeur - on note au passage que l'écart en faveur de Nvidia augmente. En augmentant la charge côté GPU avec le passage en 1920*1080 et surtout en 1920*1080 MSAA 4x les écarts de puissance entre les GPU se font sentir, le temps de traitement GPU étant devenu le facteur limitant pour le framerate final. Cela permet par exemple à la R9 290X 'Uber' de logiquement repasser devant la GTX 680, la GTX 780 Ti OC étant en tête sous ce jeu.

Avoir une bonne connaissance de ces principes peut vous être très utile en pratique. En effet, si vous éprouvez des ralentissements dans un jeu, il vous sera désormais aisé de savoir si vous êtes plutôt limité par la puissance processeur ou plutôt par la puissance GPU que vous avez à disposition : baissez les paramètres qui impactent exclusivement son temps de rendu, comme l'anticrénelage ou la résolution (tout en conservant le même ratio) : si le framerate augmente alors vous étiez très probablement limité par le GPU. Pour obtenir de meilleure performance en pratique sans baisser la résolution - et sans changer de GPU - vous pourrez si vous ne voulez pas faire de sacrifice sur la résolution désactiver les effets de post-processing par exemple tel que le flou de mouvement si ils activés. Il vous sera également possible de changer de GPU sans craindre d'être limité par le processeur, tout du moins sur le jeu et la scène utilisée.

A contrario si le framerate n'augmente pas malgré cette baisse de paramètres jouant sur la charge GPU, vous êtes probablement limité par la vitesse du traitement du processeur dans toute la partie préalable au rendu GPU, une charge qui peut également être impacté par l'optimisation des pilotes graphique. A défaut de changer votre processeur ou de l'overclockez, vous pouvez jouer sur des paramètres jouant principalement (mais pas exclusivement) sur lui, par exemple le nombre d'objets visible dans la scène (via un niveau de détail spécifique ou la distance de vue).

Ceci étant dit nous allons maintenant pouvoir passer aux mesures concernant le sujet de l'article, à savoir la mesure des écarts de performances dans des cas "CPU limited" entre AMD et Nvidia.

Crysis 3


Sous Crysis 3 nous utilisons une sauvegarde sur une zone particulièrement chargée du jeu dans laquelle nous avançons pendant 20s afin d'avoir un framerate moyen. Les tests sont effectués en 1920*1080 Very High, sans anti-aliasing.



Que ce soit sur processeur AMD ou Intel, les pilotes Nvidia permettent d'offrir des performances supérieures d'un peu plus de 8% en cas de limite processeur comme sur notre scène de test.

Arma III


Pour Arma III nous chargeons une sauvegarde lors d'un entrainement en hélicoptère dans laquelle nous survolons pendant 20s l'ile de Stratis. Les tests sont effectués en 1920*1080 Ultra, sans anti-aliasing.



Le comportement est différent sous Arma III puisque cette fois ce sont les pilotes AMD qui sont les plus véloces sur Core i5 (+2,5%), avec un très léger avantage pour Nvidia sur AMD FX.

X-Plane 10


X-Plane 10 est autant un jeu qu'un logiciel de simulation de vol. Nous utilisons 20s du benchmark intégré qui est un replay d'une approche d'un survol en basse altitude d'une ville et d'un aéroport avec les options –fps 3 qui correspondent à un niveau de détail très élevé, en 1920*1080 sans anti-aliasing.



X-Plane est le seul jeu OpenGL de notre protocole de test et il permet aux processeurs lorsqu'ils sont combinés avec des pilotes Nvidia d'afficher des performances environ 10% plus élevées qu'avec les pilotes AMD.

F1 2013


F1 2013 est notre quatrième jeu, nous utilisons le benchmark intégré qui est modifié afin d'avoir un départ du GP d'Abu Dhabi sous un temps pluvieux. Nous mesurons le framerate moyen durant les 20 premières secondes du départ, en 1920*1080 Ultra sans anti-aliasing.



Sous F1 2013 l'écart est important, ainsi sur le FX-8350 les pilotes Nvidia sont 15% plus rapides, contre 9,8% sur le Core i5-4670K.

Watch Dogs


Le framerate de Watch Dogs est pour sa part mesuré lors d'une course de 20s dans une partie assez chargée du jeu. Nous avons trouvé des scènes avec des framerate 10 à 20% inférieurs mais le système de sauvegarde automatique nous a empêché de les utiliser de manière très reproductible, tout comme l'environnement changeant. Les performances sont mesurées en 1920*1080 avec un niveau de qualité générale à Ultra mais sans anti-aliasing.



Watch Dogs est le jeu sur lequel les pilotes AMD sont le moins à l'aise en cas de limite processeur, avec un avantage de 25% pour Nvidia sur FX-8350 et 13,6% sur i5-4670K. Du coup, si avec une carte Nvidia les deux processeurs ont des performances proches, avec une carte AMD l'i5 prend un avantage plus net !

Total War : Rome II


Pour Total War : Rome II nous mesurons simplement le framerate lors de la première scène de jeu du prologue, en 1920*1080 Extreme mais en désactivant l'AA et le SSAO.




Sous Total War Rome II on note un avantage de 7,2% en faveur de Nvidia sur FX-8350 et 5,6% sur i5-4670K.

Company of Heroes 2


Pour Company of Heroes 2 nous utilisons les 20 dernières secondes du benchmark intégré pour obtenir un framerate moyen en 1920*1080 et qualité maximale exception faite de l'anti-aliasing.



Là encore l'avantage est à Nvidia avec 7% de mieux face aux pilotes AMD sur FX-8350 et 2,6% sur i5-4670K.

Anno 2070


Enfin pour Anno 2070 nous chargeons une sauvegarde d'une cité de 220 000 habitants que nous visualisons pendant 20s depuis une vue éloignée, le tout en 1920*1080 avec réglages très élevés et toujours sans anti-aliasing.



Nvidia finit de nouveau devant avec un avantage de 6,7% sur processeur AMD et 3,6% sur processeur Intel.

Conclusion

Si les résultats sont disparates, à l'exception d'une mesure ils montrent tout de même un avantage notable des pilotes Nvidia pour ce qui est de la demande en puissance processeur. En moyenne cet avantage est de 6,2% sur Core i5-4670K, et il monte même à 10,3% sur AMD FX-8350, probablement du fait d'une meilleure utilisation de ses multiples cœurs, un comble !

C'est Watch Dogs qui est le plus défavorable aux Catalyst, avec 13,6% de mieux sur i5 et 25,1% sur FX, et à contrario sous Arma III les pilotes AMD sont 2,6% plus rapides, contre 1,3% de mieux à Nvidia sur i5.

Ce n'est un secret pour personne, depuis des années maintenant Nvidia est en meilleure santé financière qu'AMD et il peut du coup attribuer plus de ressources au développement des pilotes. Avec des équipes plus limitées, il est logique qu'AMD s'attache aux optimisations les plus visibles, c'est-à-dire celles permettant d'obtenir les meilleures performances GPU, néanmoins il est vraiment dommage que cela se fasse au détriment des performances CPU dans les jeux, même si ces dernières sont moins souvent un facteur limitant.

Pour autant, AMD ne délaisse pas nos processeurs comme le démontre l'API Mantle qui a fait ses premiers pas en janvier avec Battlefield 4. Une initiative qui n'est sans doute pas étrangère à l'annonce d'un DirectX 12 très similaire par Microsoft quelques mois plus tard et dont on attend l'arrivée pour 2015. Ces évolutions promettent une bien bien meilleure utilisation de nos processeurs demain, voire aujourd'hui pour les quelques titres profitant de Mantle. Reste qu'en attendant dans la grande majorité des cas à l'heure actuelle l'avantage semble être du côté de Nvidia.

Vos réactions

Top articles