Les contenus liés aux tags AMD et CrossFire

Nous étions revenus dans notre test de la Radeon HD 7990 sur la question des saccades observées sur des configurations CrossFire lorsque l'on désactive la synchronisation verticale. Le problème est lié à la synchronisation assez difficile à réaliser entre un processeur et deux GPU qui peuvent travailler simultanément sur des images dont le rendu se termine quasi simultanément. Tous les moteurs de jeux ne sont pas touchés de la même manière et divers mécanismes sont envisageables, au niveau du pilote, pour tenter de compenser le problème.

AMD avait mis à notre disposition en avril dernier une préversion d'un pilote qui tente de cadencer les GPU, et sur lequel notre premier avis était assez mitigé. Son développement à continué et devait être terminé pour le mois de juillet. AMD a annoncé par le biais d'un tweet  que ce nouveau pilote serait mis à disposition le 31 juillet.

A l'occasion d'un long article sur le sujet , AnandTech indique qu'AMD compte (enfin!) mettre en ligne en juillet un pilote réglant le problème de micro-saccades rencontré de manière plus ou moins fréquente, principalement en CrossFireX lorsque l'on désactive la synchronisation verticale. Un problème lié à la technologie AFR (Alternate Frame Rendering) qui n'est pas tout neuf puisque nous en avions déjà parlé en... mars 2000, sur la Rage Fury MAXX !

Ce pilote laissera à l'utilisateur le choix entre deux réglages. Le premier correspond au comportement actuel, c'est-à-dire que l'image sera affichée dès qu'elle est prête, alors que le second décalera dans le temps l'affichage d'une image si elle est trop proche de la précédente.

Si le comportement actuel, qui correspond à une non prise en compte du problème, permet d'être au plus près de l'action il peut aussi entraîner des problèmes de fluidité (micro-saccades) dans les cas où peu de temps sépare les images rendues par chacun des GPU. On peut ainsi avoir des images qui restent dans le frame buffer (la partie mémoire lue pour l'affichage à l'écran) pendant 2ms, 40ms, 2ms, 40ms etc… ce qui donne une impression de fluidité moindre que si on était sur 21ms, 21ms, 21ms, 21ms, etc… pour une moyenne qui reste pourtant dans les deux cas à 21ms soit 47,6 fps.

Décaler les images qui arrivent trop rapidement n'est pas une nouveauté et c'est le choix que fait Nvidia depuis longtemps en SLI sous le nom de frame metering. Cela entraine toutefois une latence plus importante sur le rendu graphique de certaines images, dans le cas cité plus haut il faut ainsi rajouter 19ms de présence à l'écran sur les images les plus "rapides" (temps qui sera déduit sur les plus "lentes"). Dans certains cas le choix actuel d'AMD, qui sera toujours possible, permet donc d'afficher une image plus récente par rapport à l'état du jeu.

Attention, ce problème de variabilité est surtout présent lorsque la synchronisation verticale n'est pas activée, ce qui est le cas lors des mesures de performances afin que celles-ci soient les plus précises possibles, mais aussi pour certains utilisateurs qui préfèrent ce mode considéré généralement comme plus réactif. Si la qualité d'affichage est en effet réduite, du fait de cassure pouvant apparaître à l'écran puisque plusieurs images distinctes rendues peuvent se suivre sur une même affichée, c'est aussi le mode qui permet d'avoir une image affichée au plus proche de l'état du jeu. Beaucoup préfèrent conserver la synchronisation verticale active et ne sont alors pas concernés par ce problème, ceux qui préfèrent conserver la synchronisation verticale désactivé peuvent utiliser un limiteur de framerate comme ceux intégrés dans MSI After Burner ou Radeon Pro pour le contourner.

La variabilité des latences inter-image est un sujet qui fait débat depuis l'introduction par The Tech Report  d'un protocole de test mesurant cette dernière à l'aide de FRAPS. Ceci a permis fin 2012  de mettre le problème en avant chez AMD sur certains titres DX9 en mono GPU (la source de ces micro-saccades est autre qu'en CFX, et a été corrigée via des pilotes récents, d'autres corrections pour les titres DX10 et plus sont à venir).

Il faut toutefois noter que le fonctionnement même de FRAPS fait que la mesure de latence inter-image ne se fait pas au bon endroit dans le rendu graphique global et n'était donc pas forcément synonyme d'un problème réel à l'affichage (et vice-versa). Fraps mesure en effet le temps qui s'écoule entre deux appels DirectX de rendu de frame, et non le temps entre les deux affichages de l'image.

Source : AnandTech 
Ce sujet refait surface à l'occasion de la mise à disposition de testeurs par Nvidia d'un nouvel outil plus adéquat (présenté par PCPer ici , là  ou encore ici et utilisé là ), le FCAT pour Frame Capture Analysis Tool (présenté par Nvidia sur son blog aujourd'hui ). La publication de l'article d'AnandTech sur le sujet, qui précède donc une vague de publications sur le sujet (en sus de PCPer, AnandTech  et Tom's Hardware  viennent de lui consacrer un dossier) et qui fait suite à un entretien avec les équipes d'AMD, n'est sans doute pas étrangère à ceci : c'est ce qu'on appelle du Damage Control. Reste donc à voir si les paroles seront suivies d'actes, et si ces pilotes résoudront également le comportement souvent très problématique du CrossFireX en tri-écran.