Actualités cartes graphiques

Depuis quelques temps il est de plus en plus question de l'abandon des mesures de types FPS pour représenter les performances des cartes graphiques au profit de "frame times" ou de latences inter-images aptes à mettre en avant les micro-saccades et autres problèmes de fluidité. Nous n'ignorons bien entendu pas tous ces développements et à alors que nous prévoyons de publier demain un test qui ne pourra pas éviter la question de la fluidité, il nous a semblé intéressant de partager nos réflexions sur le sujet. En l'état, nous n'utiliserons pas FCAT.


Pour rappel, il y a un an et demi, notre confrère Scott Wasson de The TechReport  a entrepris d'essayer de quantifier objectivement le ressenti en terme de fluidité d'affichage qu'apportent les différentes cartes graphiques. Les FPS traditionnellement présentés représentent une moyenne qui à elle seule ne peut bien entendu pas tout vous dire concernant la fluidité.

Depuis lors, d'autres médias ont suivi le mouvement, certains par conviction, d'autres par opportunisme, et Nvidia a progressivement distribué à la presse technique un outil qui représente la solution ultime, tout du moins potentiellement. FCAT, pour Frame Capture and Analysis Tools, consiste à enregistrer le signal vidéo tel qu'il est transmis à l'écran et à ensuite analyser les différentes images qui ont été taguées au préalable pour faciliter leur identification.

Cela fait 2 mois que nous disposons de cet outil et bien plus longtemps que nous envisageons différentes solutions pour vous donner plus d'informations qu'une simple mesure de FPS. Pourquoi n'avons-nous donc toujours rien fait dans ce sens ? Parce que… ce n'est pas si simple de le faire bien.

FCAT vs Fraps

Traditionnellement, en dehors de quelques outils de test intégrés aux jeux, c'est l'utilitaire Fraps qui est utilisé pour mesurer les performances. Fraps est très bien adapté pour mesurer les performances moyennes d'une carte graphique, mais moins bien pour observer les performances image par image et donc la variabilité de la latence inter-image qui permet de se donner une idée de la fluidité de l'affichage.

Grossièrement, Fraps mesure les performances au niveau du moteur de rendu, à travers une empreinte temporelle qui sera comparée entre deux images pour en déduire le temps de rendu. Fraps n'a pas connaissance de ce qui se passe ensuite, et il se passe beaucoup de choses au niveau du pilote, des API et du GPU, d'autant plus que par défaut un buffer de quelques images prêtes au rendu (typiquement 3) est utilisé. Dans le meilleur des cas, ce dernier point fait que les relevés de Fraps au niveau d'une seule image sont corrects mais décalés dans le temps, proportionnellement au nombre d'images présentes dans le buffer.

Il est cependant courant que pour une raison ou pour une autre une image prenne plus de temps à être préparée qu'une autre et que ce buffer amortisse cette variabilité. Fraps peut ainsi laisser penser que le rendu souffre de micro-saccades alors que ce n'est pas le cas. A l'inverse, Fraps peut laisser penser que le rendu est parfaitement fluide alors qu'en pratique la cadence d'affichage n'est pas régulière, par exemple parce que 2 GPU qui travaillent ensemble ne sont pas bien synchronisés.

Ainsi Fraps n'est pas adapté à mesurer la latence inter-image, mais cela n'a jamais été le but de l'utilitaire. FCAT par contre permet d'observer la latence inter-image réelle. Reste encore à en déduire quelque chose de fiable et de pertinent.

Notez qu'une mesure type "frame time" n'est rien d'autre que l'inverse des FPS instantanés. Si certains ont tendance à parler de ms pour créer une distinction avec des FPS "classiques", il y a derrière cela également des raisons cosmétiques : il est par exemple plus facile de représenter 0 ms qu'une infinité de FPS sur un graphe.

La latence inter-image sans vsync

Sans synchronisation verticale, la latence inter-image prend une signification particulière, qui fait d'ailleurs que nous estimons son nom mal adapté. Elle représente alors la visibilité de l'image calculée par le GPU qui correspond au temps d'affichage * la proportion de l'écran qu'elle a couverte. Par exemple, en 60 Hz, une latence inter-image de 8 ms ne veut pas dire que vous verrez une nouvelle image tous les 8 ms, mais bien que cette image sera visible pendant 16.7 ms sur à peu près la moitié d'un écran.

Les scripts Nvidia

Nvidia fournit avec FCAT sa propre vision de l'interprétation des données de latences inter-images, elle a été reprise telle quelle par certains confrères. Nous ne sommes cependant pas d'accord avec l'approche de Nvidia qui consiste grossièrement à utiliser les latences inter-images pour réinterpréter le niveau de performances en déduisant des FPS quand il estime qu'une image n'a pas participé à améliorer la fluidité soit parce qu'elle n'a pas été affichée, soit parce qu'elle n'a été affichée que sur une petite partie de l'écran.

Cette approche permet de favoriser les systèmes graphiques qui débitent des images d'une façon constante, ce qui au passage est une bonne chose. Le problème est qu'à un niveau de performances suffisamment élevé, l'absence de constance n'impacte pas toujours la fluidité. Par exemple, à 120 fps, si une image sur deux n'est pas affichée ou uniquement sur quelques lignes à une extrémité de l'écran, la fluidité sera respectée, grâce en quelque sorte à une "irrégularité régulière". C'est un cas courant en multi-GPU. A l'inverse si toutes les images étaient affichées chacune sur la moitié d'un écran, des artéfacts de type déchirure de l'image (tearing) pourraient être gênants. Est-il bien pertinent de diviser le niveau de performances d'une carte par deux dans le premier cas ? Nous ne le pensons pas.

Pour être plus précis, nous ne pensons pas qu'impacter artificiellement les performances reportées de quelque façon que ce soit représente la solution. Le niveau de performances est l'aspect le plus visible dans les tests de cartes graphiques, ce qui explique que ce soit à travers lui que Nvidia essaye de mettre en avant un avantage compétitif éventuel. Nous pensons que c'est une erreur pour la presse de suivre cette voie. Les performances doivent rester ce qu'elles sont. Elles devraient plutôt être complémentées par une notion qui représente la fluidité.

La fluidité étant en partie subjective, il est tentant de modifier des données objectives, en oubliant que cette modification se fait elle-même sur base de critères totalement subjectifs. Cette partie subjective n'est pas le seul problème.

Les moteurs de jeu et le temps

Des performances élevées et une bonne régularité d'affichage ne sont pas suffisantes pour garantir une bonne sensation de fluidité. Encore faut-il que le jeu lui-même avance par étapes régulières. Cela peut paraitre trivial mais il s'agit d'une problématique importante pour les développeurs de jeux vidéo sur PC. Compte tenu des nombreuses configurations différentes, le moteur de jeu ne peut pas connaître à l'avance ni à quel moment l'image qu'il prépare sera affichée ni à quelle vitesse elle sera traitée. Se pose alors la question de savoir à quelle vitesse faire avancer la simulation du jeu.

Plusieurs techniques sont utilisées : estimer le temps de rendu sur base de l'image précédente ou de quelques images précédentes, avancer à une vitesse constante limitée à 30 ou 60 FPS (comme sur console), découpler la simulation du rendu etc. Chacune de ces approches a des avantages, des inconvénients et impacte la fluidité des mouvements à l'écran. Le moteur du jeu se base sur des données similaires à celle de Fraps et n'a pas connaissance de ce qui se passe ensuite. Il peut donc faire une erreur, avancer la simulation trop vite ou trop lentement et causer des micro-saccades dans les mouvements. Si sa simulation est limitée en FPS, même pour une partie uniquement des objets, la fluidité sera également impactée et ne correspondra ni aux FPS ni à la latence inter-image.

La latence inter-image seule n'est donc pas suffisante, il faut également s'assurer que les mouvements à l'intérieur des images soient réguliers.

Saccades : causes multiples

Les saccades et micro-saccades d'affichage ou de mouvement qui affectent la fluidité peuvent avoir de nombreuses causes dont les côtés aléatoires et spécifiques à certaines situations bien précises rendent l'analyse en profondeur de leur impact difficile voire pas pertinente du tout. Nous avons pu observer des micro-saccades spécifiques à certaines résolutions, à certaines options graphiques, à la combinaison avec certains CPU (HyperThreading), à la proximité de la limitation CPU, à l'activation du PCI Express 3.0, à des outils de monitoring, à certains niveaux de certains jeux, à certains systèmes d'exploitation, à certains types de déplacements dans un jeu, etc., et bien entendu à certains GPU et certains systèmes multi-GPU.

Il faut ajouter à cela que patches et pilotes modifient régulièrement le comportement d'une carte graphique dans un jeu et que certaines saccades sont tout simplement aléatoires, sans aucun lien avec le jeu ou le GPU observé.

Les tests sans vsync

Les tests de cartes graphiques se font généralement sans synchronisation verticale, pour plusieurs raisons. Cette option, qui garantit que les images sont affichées dans leur entièreté, sans déchirure, peut causer de gros ralentissements et augmenter la latence d'affichage. Le premier point est évité avec un niveau de performances suffisant alors que le second est souvent négligeable pour le joueur classique au vu de la latence totale, entre le mouvement de la souris et l'affichage à l'écran.

En réalité la raison principale qui fait que la majorité des tests se font avec synchronisation verticale désactivée tient au fait qu'il est ainsi plus simple de comparer les performances des cartes graphiques entre elles d'une manière générale. Nous pouvons observer leur niveau de performances maximal et en déduire plus facilement leur comportement en dehors des cas spécifiques testés.

Dans un sens, par rapport aux usages normaux des cartes graphiques, la généralisation des tests sans synchronisation verticale peut être vue comme une aberration nécessaire. Le problème est qu'il est plus complexe de garantir une cadence d'affichage régulière sans synchronisation verticale, d'autant plus que nous devons dans certains cas bidouiller les jeux pour passer dans ce mode et ainsi pousser le moteur graphique à essayer d'être régulier dans des conditions pour lesquelles il n'a pas été conçu.

Si une bonne fluidité sans synchronisation verticale est bien entendu désirable, n'est-il pas au moins aussi intéressant de s'attarder à ce qui se passe quand la synchronisation verticale est activée ? Si un système bi-GPU a des soucis de synchronisation sans synchronisation verticale, est-ce toujours vrai avec ? Est-il bien correct de se contenter de tester le premier cas et d'impacter les performances reportées en cas de problème de fluidité tout en ignorant le second cas ?

FCAT prend du temps

FCAT prend du temps, beaucoup de temps, trop de temps. Et pourtant comme nous venons de l'expliquer, en l'état et sans développement supplémentaire, l'approche proposée par Nvidia ne permet pas de répondre d'une manière complète à la question de la fluidité.

Certes disposer de valeurs fiables pour les latences inter-images est intéressant, mais cela vaut-il le temps nécessaire pour les extraire ? Nous consacrons énormément de ressources (et de nuits blanches) sur nos tests GPU et si nous ne sommes pas contre les faire évoluer, nous devons être réalistes. Pour faire face à ce problème, nos confrères qui ont opté pour une méthode de type FCAT ont en général dû sacrifier la diversité des jeux, des cartes ou des résolutions testées, ce qui est paradoxal puisque la fluidité est justement très spécifique à chaque situation.

Actuellement, nous estimons qu'il est préférable d'accepter le côté subjectif de la fluidité et de le déterminer de la sorte, en jouant. C'est ce que nous ferons dans le test de demain, en nous aidant, pour préciser notre sensation, d'un overlay qui permet d'identifier les images de manière à donner une idée du cadencement (RivaTuner Statistics Server en mode FCAT 2, 3 ou 4 colonnes). Typiquement, nous continuons à jouer 2-3 minutes après avoir mesuré les performances et notons notre impression, ce qui au passage revient déjà à doubler le temps de test. Cela reste cependant plus réaliste à ce niveau que FCAT et nous avons pu conserver 13 jeux et 3 résolutions dans notre protocole, ainsi que conserver la flexibilité suffisante pour tester des pilotes qui arrivent en dernière minute.

Progressivement, nous essayerons également d'observer régulièrement le comportement des différentes solutions graphiques lorsque la synchronisation verticale est activée.

Tout ceci ne veut pas dire que le système FCAT va prendre la poussière entre 2 piles de cartes graphiques entassées dans notre labo. FCAT est utile pour observer de plus près certains cas particuliers et nous n'avons pas encore abandonné l'idée de pouvoir en tirer un jour des données qui représenteront réellement la fluidité tout en nous permettant de vous proposer un test suffisamment riche avant que la carte graphique ne soit périmée.

Si vous nous avez suivis jusqu'au bout, n'hésitez pas à nous donner votre avis sur les méthodes de tests dans les commentaires !

Nos confrères de VR-Zone  publient un autre slide pris rapidement en photo donnant des indications sur les plans d'Intel pour 2014 et même 2015 pour la plate-forme Desktop.

A défaut de Broadwell 14nm sur Desktop en LGA il est question d'une mise à jour de la plate-forme Haswell. Si le slide fait bizarrement mention en bas d'un ensemble Haswell / Lynx Point couvrant à la fois les plates-forme Shark Bay et Haswell Refresh, on peut penser que cette mise à jour se fera autour des nouveaux chipsets Z97 et H97 apportant le support du SATA Express. Pour le 14nm et une nouvelle architecture en LGA il faudra donc attendre Skylake qui est prévu pour le premier semestre 2015.

Côté très haut de gamme Intel devrait lancer fin 2014 un Haswell-E. Comme leurs équivalents Xeon Haswell-EP, ils utiliseront un nouveau Socket et une nouvelle plate-forme dénommée Lituya Bay côté Desktop. Si nos confrères parlent de DDR4 pour Haswell-E sans qu'il en soit fait mention sur la photo, il est jusqu'alors question côté serveur de la DDR3-2133, reste donc à savoir ce qu'il en sera réellement.

Sapphire vient d'annoncer le lancement d'une nouvelle Radeon HD 7790, la Sapphire HD 7790 2GB OC . Basée sur le même refroidissement à un ventilateur que la version 1 Go classique, elle fonctionne à 1050 MHz côté GPU et 1,7 GHz côté mémoire soit 5% et 6,7% de mieux que les fréquences officielles. Si la mémoire reste de type GDDR5, elle passe par contre de 1 à 2 Go.

Sapphire n'est pas le premier à lancer une telle carte puisque la Gigabyte GV-R779OC-2GD  est déjà disponible. On a droit cette fois à un refroidissement à double ventilateur, un GPU à 1075 MHz et de la GDDR5 à 1,6 GHz.


Seul problème, il faut compter 20 à 30 € de plus pour cette carte par rapport à un modèle 1 Go. Alors que le GPU Radeon HD 7790 ne permet pas d'utiliser une combinaison de niveau de détails et de résolution nécessitant plus d'1 Go de GDDR5 à ce jour, on est donc au-dessus du prix d'une Radeon HD 7850 1 Go qui sera plus performante en pratique.

Si les 2 Go sont tout de même pour vous un argument de poids, les Radeon HD 7850 2 Go et GeForce GTX 660 2 Go, notablement plus rapides, sont à peines plus onéreuses. Vous l'aurez compris, à ces tarifs les HD 7790 2 Go, tout comme les GeForce GTX 650 Ti Boost 2 Go, n'ont pas vraiment d'intérêt.

Mise à jour du 16/04 : Nvidia vient d'officialiser l'offre ce mardi 16 avril. Les GeForce GTX 660 et supérieures sont donc concernées par ce nouveau bundle qui remplace le crédit de 110 € dans des jeux Free-to-Play (certains commerçants pourront toutefois proposer les deux si ils leurs restent des codes). Les cartes GTX 650, 650 Ti et 650 Ti Boost conservent le crédit de 55 € pour les jeux jeux Free-to-Play. Comme d'habitude il faudra veiller à ce que le commerçant propose l'offre Nvidia.

News du 13/04 : Après l'offensive d'AMD, qui vient d'être complétée par l'intégration de Far Cry 3 Blood Dragon, et une tentative dans le Free-to-Play qui n'a pas réellement convaincu, Nvidia se devait de réagir avec le retour d'un bundle jeu "AAA". Selon Techpowerup , ce titre sera le très prometteur Metro Last Light dont la sortie est prévue pour le 17 mai.

Ce nouveau bundle concernerait les GeForce GTX 660 et supérieures, sans que l'on ne sache si il viendra en complément du bundle Free-to-Play, si il le remplacera ou si les deux bundles coexisteront. Nvidia devrait officialiser cette offre dans le courant de la semaine prochaine, nous devrions donc en savoir plus d'ici quelques jours.