Ashes of the Singularity et DirectX 12 : AMD vs Nvidia
Après deux années de gestation, DirectX 12 s'apprête enfin à devenir réalité avec l'arrivée des premiers jeux développés pour cette nouvelle API graphique plus efficace. A la clé, des gains de performances potentiellement significatifs autant du côté CPU que du côté GPU et la dernière version beta d'Ashes of the Singularity est l'occasion d'observer tout cela de plus près à travers un premier match AMD vs Nvidia sous DirectX 12.
Libérer le CPU
Ashes of the Singularity est un jeu de stratégie en temps réel développé par Oxide Games et Stardock Entertainment. La particularité de ce jeu est de mettre en scène des combats de vaste envergure qui peuvent impliquer des milliers d'unités. Très complexes à représenter à l'écran, ces scènes massives ont tendance à étouffer les CPU de nos PC avec une avalanche de commandes de rendu dont le coût de traitement peut être très élevé avec les API traditionnelles.
Un cas d'école donc pour les nouvelles API de plus bas niveau dont l'intérêt principal est de libérer un maximum de puissance CPU d'une part en réduisant le coût des commandes de rendu et d'autre part en facilitant l'exploitation de l'ensemble des cœurs des CPU. Rien n'est gratuit cependant et en échange de ces bénéfices, le travail des développeurs se complexifie notamment au niveau de la fiabilité de leur code puisque ces API allégées ne feront plus automatiquement toutes sortes de vérifications de sécurité à leur place. Entre performances et robustesse, c'est au final le talent des développeurs qui sera mis à l'épreuve.
Illustrations des bénéfices de DirectX 12 au niveau de l'exploitation des CPU multicores. Dans cet exemple les performances sont presque doublées.
Le Multi Engine pour mieux exploiter les GPU
Avec Ashes of the Singularity, un autre aspect important de Direct3D 12 est mis à l'honneur : le Multi Engine. Cette spécificité des nouvelles API permet aux développeurs de mettre en place plusieurs files d'attente de commandes de rendu, de prendre le contrôle sur la synchronisation entre celles-ci et dans certains cas d'exécuter ces tâches simultanément ou en concomitance. De quoi potentiellement mieux exploiter le GPU en le faisant travailler en parallèle sur plusieurs phases du rendu qui s'accordent bien, c'est ce qu'AMD met en avant sous le terme "Async Compute/Shading".
Imaginez par exemple une première phase du rendu qui applique les textures et enregistre une préversion basique des pixels (remplissage du G-Buffer). Cette phase va saturer l'interface mémoire et une partie des unités de calcul vont se tourner les pouces. Imaginez maintenant une autre phase du rendu pendant laquelle un effet de post processing complexe est appliqué via un Compute Shader. Cette fois les unités de calcul tournent à plein régime mais peu de données sont écrites en mémoire. Pouvoir exécuter ces deux phases en même temps présente alors un intérêt évident sur le plan de performances. C'est ce que permet de faire le Multi Engine.
Illustration du Multi Engine de DirectX 12. Dans cet exemple extrême les performances progressent de 50%.
Pour Direct3D 12, Microsoft a repris à ce niveau exactement la structure qu'AMD avait proposée avec son API Mantle, mais sans obligation de résultat, l'implémentation matérielle qui en découle étant laissée à l'appréciation des fabricants de GPU. Autrement dit, tous les pilotes doivent accepter les files d'attentes multiples et les commandes de synchronisation entre elles, mais rien ne les oblige à les exécuter en parallèle. Si un GPU en est capable, le pilote peut lui permettre de profiter du gain de performances, si un GPU n'en est pas capable, le pilote va simplement lui faire traiter les différentes tâches en série, exactement comme avec une API classique. Il n'y aura alors aucun gain de performances mais plutôt une petite perte liée aux commandes de synchronisation qui ne sont pas gratuites.
Vous pourrez retrouver plus d'informations sur tout cela dans cet article dédié : Les GTX 900 supportent-elles correctement DirectX 12 ?. Comme son intitulé l'indique, il y a une grosse interrogation sur les capacités des GPU Nvidia face au Multi Engine. Contrairement à AMD qui a détaillé ce dont sont capables ses Radeon, depuis l'annonce de DirectX 12, Nvidia a toujours refusé de communiquer clairement sur les capacités de ses GPU et nous soupçonnons que les GeForce, y compris Maxwell de seconde génération, ne disposent pas d'un processeur de commande suffisamment évolué pour pouvoir profiter pleinement du Multi Engine.
En septembre dernier, une précédente version beta d'Ashes of the Singularity pointait vers un petit déficit de performances des GeForce en DirectX 12, ce qui, comme vous vous en doutez, n'était pas du goût du service de communication de Nvidia qui apprécie peu que la domination des GeForce soit remise en question. Nvidia indiquait alors que le Multi Engine n'était pas encore implémenté dans ses pilotes, que le moment venu ses pilotes seraient à la hauteur et qu'il y aurait de meilleurs exemples de performances en DirectX 12 avec d'autres jeux. Nous allons voir si la situation a évolué sur ce point.
Notons enfin sur ce sujet que tout l'art de l'exploitation du Multi Engine est de parvenir à mettre en place des optimisations qui sont globalement utiles à un maximum de GPU ou spécifiques à chaque GPU. Suivant l'équilibre de l'architecture de ceux-ci, certaines combinaisons de tâches apporteront des gains plus ou moins importants.
Plus de flexibilité pour le multi-GPU
Enfin, la troisième nouvelle possibilité offerte par DirectX 12 et exploitée par Ashes of the Singularity concerne le support explicite du multi GPU. Les API de plus bas niveau permettent aux développeurs d'en prendre le contrôle et de faire à peu près tout ce qu'ils veulent, y compris exploiter simultanément des GPU de type et de marque différente.
La version actuelle d'Ashes of the Singularity implémente un mode AFR (chaque GPU traite une image en alternance) géré explicitement par le moteur du jeu. Toute association de carte graphique est donc possible mais il faut garder en tête, AFR oblige, que le niveau maximal de performances ne pourra jamais être supérieur à 2x celui de la carte la plus lente. Il reste donc important que le niveau de performances entre les cartes graphiques soit similaire. Associer une GeForce GTX 980 Ti à une Radeon R9 Fury X devient ainsi possible.
Malheureusement, nous n'avons pas pu tester cet aspect. Malgré de nombreuses tentatives, le jeu a refusé de se lancer sur notre système de test dans ces conditions. Après quelques observations supplémentaires, le problème semble venir de notre système de test qui se contente de 8 Go de mémoire, ce qui est insuffisant face à l'utilisation mémoire qui est de toute évidence supérieure lorsqu'un moteur de jeu doit jongler entre deux pilotes différents. Nous tâcherons de revenir sur ce point un peu plus tard.
Ceci dit, bien qu'intrigante, cette possibilité reste selon nous anecdotique dans l'immédiat, en partie parce que nous nous attendons à quelques petits défauts visuels, notamment au niveau du filtrage des textures, mais surtout parce qu'il y a peu d'intérêt à prévoir aujourd'hui un système dont la puissance graphique combinée ne pourrait être exploitée que dans quelques jeux.
Plus intéressant, Oxide étudie la possibilité d'implémenter un mode SFR (partage de l'image entre GPU) ou de répartition des phases de rendu. De quoi cette fois permettre d'associer des GPU au niveau de performances différent, ce qui permettrait par exemple à un GPU intégré d'assister une carte graphique ou de conserver son ancienne GeForce pour assister sa nouvelle Radeon. Entre la théorie et la pratique il y a cependant de nombreuses difficultés à la mise en place de ce type de partage des tâches.
Le benchmark
Actuellement, la seule possibilité pour tester Ashes of the Singularity autant sur Radeon que sur GeForce est de passer par le benchmark intégré au jeu.
Oxide précise que ce benchmark est en fait sa suite de test interne exploitée pour le profilage et l'optimisation des performances. Ce n'est ainsi pas un simple test graphique mais une réplique aussi réaliste que possible du comportement de l'ensemble du moteur lors d'une phase de jeu, ce qui inclut le son, l'AI ou encore la physique. Seule petite différence pour éviter trop de variations dans les résultats, toutes les unités sont dans une sorte de "god mode", c'est-à-dire qu'elles ne peuvent pas mourir durant les 3 minutes de test.
Plusieurs résultats sont fournis par cet outil d'analyse. Le niveau de fps moyen global bien entendu, mais également 3 sous-résultats : Normal Batches, Medium Batches et Heavy Batches. Ils représentent le niveau moyen de fps lors des phases normales (plutôt limitées par le GPU), moyennement lourdes et très lourdes au niveau du nombre de commandes de rendu (plutôt limitées par le CPU).
L'utilitaire estime également le niveau de fps maximal atteignable par le CPU si celui-ci était associé à une carte graphique aux performances infinies. Un chiffre approximatif qui ne nous intéresse pas réellement mais qui permet aux joueurs de savoir facilement si mettre à jour leur carte graphique est utile.
Oxide a prévu dans son fichier .ini une commande qui permet de désactiver le recours au multi engine et de n'exploiter qu'une seule file d'attente par GPU (AsyncComputeOFF). Pourquoi désactiver les files d'attente multiples et le gain de performances qu'elles peuvent apporter ? Tout simplement parce que si un GPU n'est pas capable de profiter du parallélisme, il souffrirait alors du petit coût des commandes de synchronisation sans profiter du plus large gain de performances.
A noter que la version beta actuelle du jeu, annoncée comme étant la dernière avant sa sortie le 22 mars, souffre encore de quelques bugs. De petits artéfacts de rendu sont visibles sur Radeon en mode DX11. Après 2h de tests sans rencontrer le moindre souci, les performances sont devenues incohérentes sur notre Radeon R9 380. Enfin, peu importe la carte graphique exploitée et autant en mode DX11 que DX12, le moteur du jeu semble mal gérer le mipmapping et le filtrage des textures au niveau de zoom maximal. Ainsi, d'une part il passe trop vite à une résolution de mipmap insuffisante sans avoir recours au filtrage trilinéaire, et d'autre part, à l'avant plan, il applique du point sampling... soit aucun filtrage. D'ici la sortie du jeu, Oxide a donc encore du pain sur la planche...
Nous avons effectués les tests qui vont suivre avec les pilotes conseillés par AMD et Nvidia, à savoir des Radeon Software 16.2 beta (15.301) et des pilotes GeForce 361.91 WHQL. Le tout avec un Core i7 3960X, 8 Go de DDR3 2133 et Windows 10 64 bits.
Les premiers résultats en 1080p
Nous avons tout d'abord lancé le benchmark du jeu en 1080p avec un niveau de qualité élevé, sur 3 Radeon et sur 3 GeForce, en mode DirectX 11, DirectX 12 et DirectX 12 avec AsynComputeOFF :
[ Moyenne ] [ Heavy ] [ Medium ] [ Normal ]
Ces premiers résultats mettent directement en avant deux points intéressants à observer. Tout d'abord, les performances en DirectX 11 des Radeon sont très mauvaises. Le graphe Heavy Batches précise que cela est lié à de faibles performances CPU quand les scènes sont très lourdes en commandes de rendu, ce qui implique les pilotes.
Ensuite, en mode DirectX 12, les Radeon profitent du Multi Engine pour se prendre une petite avance sur les GeForce qui, de leur côté, affichent une petite perte quand cette option est active, ce qui est le cas par défaut. Cette petite perte fait que les GTX 970 et 960 ne profitent pas de gain de performances en passant à DirectX 12 dans ce jeu.
1440p extrême et Multi Engine
Pour observer de plus près l'impact du Multi Engine, nous avons poussé d'un cran la qualité graphique de manière à réduire quelque peu l'influence du CPU. Les options graphiques passent alors du 1080p High au 1440p Extreme et nous nous contentons de mesurer les performances sur les 2 GeForce et sur les 2 Radeon les plus véloces :
[ Moyenne ] [ Heavy ] [ Medium ] [ Normal ]
Les Radeon profitent ici pleinement du Multi Engine et prennent une avance conséquente sur les GeForce.
Les deux Radeon gagnent +/- 15% de performances en moyenne, le gain le plus élevé étant observé dans les scènes de complexité moyenne. En face, les GeForce affichent un impact de 2 à 3%, ce qui confirme qu'elles ne profitent pas des bénéfices du Multi Engine mais subissent le coût des commandes de synchronisation liées à son support.
Pour aller un peu plus loin, nous avons voulu observer dans quelle mesure l'équilibre de l'architecture d'un GPU peut lui permette de profiter plus ou moins de l'implémentation du Multi Engine de Ashes of the Singularity. Pour cela, en plus des performances de base de la R9 390, nous avons réduit de moitié la fréquence de son GPU et ensuite fait de même avec la fréquence de sa mémoire. Enfin, nous avons ajouté les résultats de la R9 390X cadencée aux mêmes fréquences (+10% d'unités de calcul).
L'implémentation du Multi Engine dans Ashes of the Singularity semble plutôt bien coller à l'équilibre de l'architecture des R9 390 et 390X. Ces résultats, qui ne racontent malheureusement qu'une partie de l'histoire, semblent montrer que cette implémentation a pour première conséquence de mieux exploiter la bande passante mémoire disponible en évitant de concentrer des accès massifs à la mémoire sur une petite partie du temps de rendu.
Nous avons ensuite voulu observer l'évolution de la consommation et du rendement énergétique en passant d'un mode à l'autre. Pour cela, nous avons mesuré la consommation du système complet, à la prise à l'aide d'un wattmètre. Après avoir observé la consommation sur l'ensemble de la scène de test, nous avons opté pour 3 points de mesure :
[ DirectX 11 ] [ DirectX 12 AsyncComputeOFF ] [ DirectX 12 ]
Assez logiquement, la carte graphique étant l'élément le plus gourmand du système, plus les performances augmentent, plus la consommation augmente. En mode DirectX 11 nous pouvons observer pas mal de variation dans la consommation avec les Radeon, ce qui s'explique par la forte limitation CPU dans certains parties du test. A l'inverse, la consommation est très stable avec une GTX 970, les performances étant alors principalement limitées par le GPU.
Pour vous donner un aperçu approximatif de l'efficacité énergétique de ces systèmes, nous avons fait la moyenne des 3 mesures de consommation et nous l'avons mise en relation avec le nombre de fps moyen. Cette efficacité change peu sur GeForce, mais augmente significativement sur les Radeon, avec une R9 Fury X alors capable de prendre les devants.
Il est important d'observer que le Multi Engine ne réduit pas cette efficacité énergétique. S'il entraîne une augmentation de la consommation, d'une part en chargeant plus lourdement le GPU et d'autre part en augmentant le nombre d'images traitées par le CPU, le gain de performance y est supérieur.
768p côté CPU
Après ces séries de tests plutôt orientées GPU, nous avons voulu nous pencher sur les performances CPU. Pour cela, nous avons baissé la résolution en 768p High et avons retenu la R9 Fury X et la GTX 980 Ti. Nous avons fait varier le nombre de cœurs CPU (2, 4 ou 6) et activé/désactivé l'HyperThreading. Le Turbo était désactivé et une fréquence stable fixée.
Afin de nous pencher de plus près sur l'opposition entre un CPU équipé de peu de cœurs mais très performants et un autre équipé de cœurs plus nombreux mais moins performants, nous avons fait varier la fréquence du CPU lorsque ses 6 cœurs sont actifs. De 3.3 GHz, nous sommes passés à 2.2 GHz (pour une puissance théorique similaire à 4 cœurs à 3.3 GHz) et à 1.14 GHz. Il ne nous était pas possible de passer à 1.1 GHz compte tenu d'un multiplicateur minimum de 12. Nous nous sommes donc rabattus sur une réduction du BCLK à 95 MHz, ce qui réduit également d'autres points tels que la fréquence mémoire. Bien qu'approximatif cela permet malgré tout de comparer ce que donnent 6 cœurs peu performants face à 2 cœurs beaucoup plus performants.
[ Heavy ] [ Medium ] [ Normal ] [ Moyenne ]
En nous concentrant sur les résultats en Heavy Batches, les plus importants au niveau du CPU, nous pouvons tout d'abord constater que les pilotes DirectX 11 de Nvidia sont bien plus efficaces que les pilotes AMD. Ils permettent de doubler les performances globales et sachant qu'il y a d'autres charges CPU sur lesquelles ils ne peuvent pas avoir d'impact (AI, son, physique), la différence d'efficacité est bien plus importante encore.
Le mode DirectX 12 permet de faire exploser les performances du côté des Radeon. Elles sont plus ou moins triplées. Du côté des GeForce, le gain est plus faible mais est bien là avec à peu près 30% de mieux.
6 cœurs à 2.2 GHz avec HT sont capables de surpasser 4 cœurs à 3.3 GHz en mode DirectX 12, alors qu'en mode DirectX 11 ils restent en moyenne 19% derrière du côté d'AMD et 5% derrière du côté de Nvidia.
Pour terminer cette lecture des performances, nous avons tiré de ces mesures CPU quelques comparaisons de plus :
[ D3D12 vs D3D11 - R9 Fury X ] [ D3D12 vs D3D11 - GTX 980 Ti ] [ R9 Fury X vs GTX 980 Ti - D3D11 ] [ R9 Fury X vs GTX 980 Ti - D3D12 ]
C'est avec 2 cœurs CPU véloces que l'écart est le plus faible entre DirectX 11 et DirectX 12, ou encore entre Radeon et GeForce, ce qui est logique puisque c'est la configuration la plus simple à exploiter avec les API traditionnelles.
Autre observation intéressante, sous DirectX 12, lorsque le CPU est plutôt faiblard, c'est cette fois le pilote d'AMD qui s'en tire le mieux, même si la différence est presqu'anecdotique par rapport à l'avance de Nvidia sous DirectX 11.
Que faut-il en conclure ?
L'arrivée des jeux DirectX 12, enfin, est une bonne nouvelle pour les joueurs, tant le potentiel de ce nouveau type d'API graphique est important. Le travail pour en tirer le meilleur est cependant loin d'être terminé. D'une part pour AMD et Nvidia qui disposent probablement de pas mal de marge de manœuvre pour optimiser les pilotes et aider les développeurs à aller dans la direction la plus efficace. D'autre part pour ces développeurs qui vont devoir apprendre à exploiter au mieux les GPU avec moins d'aide des pilotes, or il n'est pas toujours simple d'égaler des années d'optimisations intégrées par AMD et Nvidia pour les API traditionnelles, même si elles sont à la base moins efficaces.
Ce ne sont bien entendu pas quelques benchmarks dans un premier jeu DirectX 12, qui plus est en version beta, qui vont permettre de tirer des conclusions définitive sur l'état du support de cette nouvelle API parmi les GPU actuels. Ashes of the Singularity permet cependant de faire quelques observations et de soulever quelques questions par la pratique.
Tout d'abord, ces tests confirment le travail effectué par Nvidia sur son pilote DirectX 11. Piqué au vif par le lancement de l'API Mantle d'AMD, Nvidia a rapidement réagi en orientant sa force de frappe niveau optimisation des pilotes sur le surcoût des commandes de rendu et l'efficacité du multithreading avec les API traditionnelles. Les résultats sont impressionnants sous Ashes of the Singularity, même si DirectX 12 permet de faire encore mieux. La généralisation des jeux DirectX 12 pourrait permettre de réorienter certains choix pour les joueurs, en donnant plus d'intérêt à des CPU aux cœurs un peu moins performants mais présents en plus grand nombre.
Ashes of the Singularity permet également de confirmer que les Radeon sont capables de profiter pleinement du Multi Engine, soit de la gestion en parallèle de plusieurs files de commandes pour maximiser l'utilisation de toutes leurs capacités. Même si ce n'est pas leur raison d'être principale, les nouvelles API sont bel et bien capables d'améliorer les performances GPU.
Mais encore faut-il que ceux-ci en soient capables. Et sur ce point les interrogations ne peuvent que se renforcer concernant les GeForce. Nvidia ne nous en dira pas plus qu'il y a 6 mois. La réponse officielle reste que le Multi Engine n'est pas encore implémenté dans les pilotes. Circulez, il n'y a rien à voir. Une réponse qui est un non-sens, puisque le Multi Engine est à la base de DirectX 12 et doit obligatoirement être pris en charge. C'est d'ailleurs à travers cette fonctionnalité que le multi GPU fonctionne. Ce que Nvidia veut probablement dire c'est qu'en l'état actuel des choses, ses pilotes n'autorisent pas l'exécution simultanée de tâches différentes et ne permettent donc pas de profiter du gain de performances qui en découle.
Il nous est cependant difficile de croire que l'implémentation dans ses pilotes d'une partie cruciale de DirectX 12 ne soit toujours pas terminée. Deux ans après l'annonce publique de l'API et 6 mois après que la première version alpha d'Ashes of the Singularity l'ait exposée ? Si les GeForce ne souffraient d'aucune limitation au niveau du Multi Engine, Nvidia serait le premier à mettre en avant cette spécificité et son support logiciel. La question n'est donc pas réellement de savoir s'il y a des limitations pour les GeForce, c'est à peu près certain maintenant, mais de savoir quelles sont ces limitations. Malheureusement, il faudra probablement attendre que Nvidia lance un nouveau GPU plus doué à ce niveau pour que les détails concernant les GPU actuels nous soient communiqués.
En attendant, il est probable que Nvidia se batte sur d'autres fronts, d'une part en essayant d'isoler d'autres opportunités d'optimisation au niveau de ses pilotes et d'autre part en mettant en avant les nouvelles fonctionnalités de DirectX 12 et 11.3 qui ne sont actuellement supportées que par les GeForce Maxwell de seconde génération (GTX 900). De quoi implémenter des effets graphiques spécifiques mais peut-être également d'autres types d'optimisations. La bataille ne fait que commencer !
Contenus relatifs
- [+] 20/03: Radeon Software 18.3.3 beta avec Vu...
- [+] 27/03: 3DMark reçoit un support limité de ...
- [+] 28/02: GDC: Wave programming pour booster ...
- [+] 20/10: Pilotes AMD Radeon Software 16.10.2
- [+] 14/09: Vulkan en novembre pour le CryEngin...
- [+] 08/09: Pilotes AMD Radeon Software 16.9.1
- [+] 25/03: GDC: D3D12, multi-GPU et frame pipe...
- [+] 23/03: GDC: Async Compute : ce qu'en dit N...
- [+] 21/03: GDC: Async Compute et AotS : des dé...
- [+] 16/03: GDC: Autre exemple DX12 avec Quantu...