Nvidia G-SYNC en test : les jeux fluides dès 40 fps ?

Tags : G-SYNC; GeForce; Nvidia;
Publié le 30/12/2013 par
Imprimer
Le dilemme de la synchronisation verticale
Si le GPU calcule directement l'image dans la zone mémoire (buffer) lue par le moteur d'affichage en vue du transfert vers l'écran, le résultat sera loin d'être à la hauteur : les images ne seront pas affichées finalisées mais en construction progressive. Pour éviter ce problème, certaines vieilles consoles n'utilisaient leur processeur graphique pour manipuler l'image que pendant le VBLANK.

Une situation intenable au fur et à mesure que les processeurs graphiques ont vu leurs fonctionnalités sa démultiplier. Ne les exploiter que pendant cette petite fraction du temps d'affichage d'une image aurait bien entendu été ridicule. La solution est le double buffering qui consiste, en acceptant une latence supplémentaire, à maintenir en permanence deux buffers. L'un est utilisé par le GPU pour le rendu de l'image (back buffer) alors qu'un autre contient l'image précédente en cours d'affichage (front buffer).

Durant le VBLANK, l'image était au départ copiée du back buffer vers le front buffer mais une optimisation a rapidement été mise en place : l'inversion des buffers. Les GPU et leurs moteurs d'affichage peuvent accéder à l'ensemble de la mémoire vidéo et il est alors plus simple et plus rapide d'inverser les pointeurs vers les adresses mémoires dédiées à chaque buffer, sans réellement déplacer la moindre donnée. Le back buffer devient front buffer et vice versa.

Voici comment cela se passe dans un cas idéal : (notez que par soucis de simplification, l'échelle des illustrations qui suivent se base sur des cycles d'affichages de 16ms, ce qui correspond à 62.5 Hz et non au classique 60 Hz)


Les rectangles verts clairs représentent le back buffer dans lequel le GPU calcule l'image, leur longueur représente ce temps de calcul. Les rectangles gris représentent le front buffer dont la longueur correspond à la période durant laquelle ils sont lus et les images sont transférées à l'écran. Vous remarquerez un petit intervalle entre les rectangles gris, c'est le VBLANK.

Le GPU inverse le back et le front buffer durant la période VBLANK, nous parlons alors de synchronisation verticale activée (V-SYNC ON). Dans le cas illustré, idéal, le GPU est capable de générer une image dans un délai inférieur au cycle d'affichage, il tourne à 60 fps constants avec une marge confortable. A chaque rafraîchissement de l'écran, une nouvelle image peut être affichée, pour une sensation de fluidité et de régularité des mouvements parfaite.

Pour cela, la carte graphique et le reste du système, doivent être capable de toujours travailler au moins à 60 fps, ou en moins de 16.7ms par image. Les développeurs peuvent s'en assurer sur console (même si en général ils visent plutôt 2 cycles de rafraîchissement et donc 30 fps constants), mais l'environnement PC divers et varié ne permet pas de faire de même. Bien des systèmes ne sont pas capables de maintenir 60 fps en permanence et donc de proposer une nouvelle image toutes les 16.7ms. C'est là que les problèmes commencent.


V-SYNC ON  [ cas parfait ]  [ cas classique ]  -  [ V-SYNC OFF ]

Toujours avec V-SYNC ON, lorsque le délai de 16.7ms est dépassé et que le GPU n'a pas terminé le calcul de la nouvelle image, l'écran doit être rafraîchi une seconde fois avec la précédente. Le résultat est une saccade peu agréable. Par exemple si la nouvelle image a nécessité un temps de calcul de 18 ms, et donc "raté" le rafraîchissement écran, elle doit attendre le suivant, et ne sera ainsi affichée qu'après un total de 33.3 ms bien supérieur à son temps de calcul et au délai idéal de 16.7 ms.

Entre 18 et 33.3 ms, le GPU est bloqué, puisqu'il ne peut inverser les buffers que pendant le VBLANK. Dans le cas où ce temps de calcul trop long n'est pas ponctuel mais généralisé, les performances se retrouvent limitées à 30 fps, voire moins, ce qui réduit la fluidité et augmente la latence.

La parade couramment utilisée par les joueurs consiste alors à désactiver la synchronisation verticale (V-SYNC OFF). Le GPU est libre d'inverser le front et le back buffer dès qu'il a terminé le calcul d'image, ignorant la période de VBLANK. Avec une carte graphique performante, les performances peuvent s'envoler bien au-delà du taux de rafraîchissement de l'écran et en cas de ralentissement, la perte de performances n'est pas amplifiée comme dans l'exemple précédent. Il n'y a plus de grosse saccade, ni de perte de fluidité généralisée.


Par contre, les buffers sont alors très souvent inversés alors que la lecture de l'image est en cours. En conséquence, l'affichage à l'écran d'une image donnée est subitement coupé pour continuer avec l'image suivante. A l'écran, nous n'observons plus une image pleine mais bien 2 (ou plus) morceaux d'images qui se succèdent. Suivant la situation, mouvement important à l'écran ou pas, la frontière entre ces 2 images est plus ou moins importante et visible, ce qui donne la sensation de cassure dans l'image (tearing en anglais).

Les problèmes de fluidité, de saccades et de latence sont réduits en VSYNC OFF, mais ils ne disparaissent pas pour autant. Si un affichage est composé de plusieurs morceaux d'images, la latence est différente pour chacun de ces morceaux et certains peuvent ne pas avoir été rafraîchis depuis l'affichage précédent. Des sensations de saccades peuvent alors se faire ressentir à leur niveau avec un impact plus ou moins ressenti s'ils se situent ou pas là où se focalise le regard du joueur. Par ailleurs, sans limite de performances, la variation du temps de rendu d'une image à l'autre va augmenter, ce qui peut impacter la régularité de leur affichage et la sensation de fluidité.

Il peut ainsi parfois être difficile pour les joueurs PC de faire le choix d'activer ou pas la synchronisation verticale, d'autant plus que le résultat va varier d'un jeu à l'autre, voire d'une scène à l'autre. Plusieurs tentatives de réponse à cette problématique ont été proposées, telles que le triple buffering ou la synchronisation verticale adaptative.


Le triple buffering
Le triple buffering n'est pas une technique récente, elle fait partie du panel de possibilités depuis de nombreuses années mais n'a pas pu représenter une solution généralisée à la problématique de la synchronisation verticale puisqu'elle souffre également de défauts.

Le triple buffering est souvent mal compris par certains joueurs en partie parce que des interprétations incorrectes de cette technique se sont répandues. Le triple buffering n'est pourtant pas bien compliqué et pousse simplement un peu plus loin le concept du double buffering. Il s'utilise exclusivement en VSYNC ON.


V-SYNC ON  [ double buffering ]  [ triple buffering ]  [ cas parfait ]

En plus du front buffer (gris) et du back buffer (vert clair), un troisième buffer, intermédiaire, est exploité (vert). L'image se déplace du back buffer ou troisième buffer et enfin au front buffer en vue d'être affichée.

Ce troisième buffer permet au GPU d'éviter dans certains cas d'être bloqué quand il a terminé son travail mais devrait en double buffering attendre la période de VBLANK pour inverser le front et le back buffer et commencer le calcul d'une nouvelle image. Cette fois, il peut placer l'image dans le troisième buffer et commencer directement le traitement de la suivante. Il y a une bien entendu une limitation importante : toutes les images doivent être affichées et si le GPU est très rapide, il se retrouve malgré tout bloqué une fois tous les buffers remplis et en attente d'affichage.

Dans cet exemple, l'image (2) prend plus de temps que la normale à être calculée. En double buffering classique, cela entraîne une saccade puisque ce retard implique que l'image (1) doit être affichée deux fois. En triple buffering, le troisième buffer est libre quand l'image (2) est finalement terminée, et cette dernière peut y prendre place directement pour permettre au GPU de libérer à son tour le back buffer et d'enchaîner sur le calcul de l'image (3). La saccade est ainsi évitée. Si toutes les images ont besoin de 18 ms pour être calculées, le GPU pourra tourner à 55 fps de moyenne, là où en double buffering il aurait été limité à 30 fps.

Toutes les saccades ne peuvent bien entendu pas être évitées de la sorte, le tampon n'est que d'un cycle d'affichage soit 16.7 ms à 60 Hz. Si le retard combiné du rendu de plusieurs images successives dépasse cette valeur, une image est affichée deux fois et une saccade apparaît. Au final, sans devenir parfaite, la fluidité progresse significativement dans bien des cas.

Le gros défaut du triple buffering est d'ajouter un cycle d'affichage de latence supplémentaire. A 55 fps en triple buffering, la latence est équivalente à celle obtenue à 30 fps en double buffering et plus élevée au moment des petites saccades.

Que font les jeux actuels ? La plupart ne proposent pas d'option à ce niveau et en V-SYNC ON, les développeurs font le choix d'activer ou pas le triple buffering à la place des joueurs, dans certains cas d'après la fréquence de rafraîchissement de l'écran. C'est par exemple le cas de Splinter Cell Blacklist qui fait appel au double buffering en 60 Hz mais au triple buffering en 120/144 Hz.


Du faux triple buffering ?
Existe-t-il un "vrai" triple buffering en opposition à un "faux" triple buffering de DirectX, semblable à ce que nous venons de décrire et qui serait en fait du "render ahead" ? C'est un point de vue selon nous erroné répandu il y a quelques années par un confrère qui exprimait probablement une opinion personnelle de ce qu'il aimerait que soit le triple buffering, sans avoir considéré tous les aspects de la question, peut être influencé par le discours simplifié de l'un ou l'autre acteur de l'industrie qui y aurait vu un moyen de donner de l'intérêt aux systèmes capables d'atteindre de très haut fps.

"Render ahead" dans le cadre de DirectX représente le buffer d'images préparées par le moteur du jeu et l'API avant l'envoi vers le GPU, de manière à lisser l'arrivée des images. Il s'agit d'un niveau de compromis supplémentaire entre latence et fluidité proposé par DirectX. Il n'a strictement aucun lien avec le double ou le triple buffering qui sont des buffers différents utilisés après le calcul des images. Render ahead peut-être utilisé dans tous les cas, aussi bien en double qu'en triple buffering, avec un niveau de profondeur par défaut de 3 images mais configurable par le développeur.

Ce qui a été décrit comme étant le "vrai" triple buffering est en fait la suppression d'une restriction de cette méthode de gestion de l'affichage. Si le GPU a terminé une nouvelle image, il la place alors directement dans le troisième buffer, même s'il contient une image qui n'a pas encore été affichée, ce qui n'est pas possible avec du triple buffering classique. Encore une fois, cela fonctionne avec ou sans "render ahead".

L'avantage est de permettre au GPU de calculer plus d'images que l'écran n'est capable d'en afficher. Le GPU peut par exemple tourner à 300 fps en 60 Hz, de quoi réduire la latence, tout en n'affichant que des images entières, sans tearing. Ce triple buffering magique reviendrait ainsi à combiner le meilleur du V-SYNC ON (pas de tearing) et du VSYNC OFF (faible latence). C'est vrai à 300 fps +/- constants, et dans ces conditions c'est probablement utile pour une poignée de joueurs professionnels.

Le problème est qu'à un niveau de fps plus réaliste pour la majorité des joueurs, par exemple 50 à 70 fps, ce triple buffering avec possibilité de sauter des images, réintroduit des saccades ou à-coups. Le moteur du jeu ne peut pas prédire qu'une image va être sautée en bout de piste et du coup les mouvements de caméra ou des éléments de la scène ne seront pas réguliers à l'écran, ce qui, du point de vue du joueur, revient au même qu'une saccade. C'est la raison pour laquelle cette possibilité, en réalité complémentaire au triple buffering, est peu appréciée de la part des développeurs qui par conséquent ne poussent ni Microsoft, ni AMD et Nvidia à l'implémenter.

A noter que c'est très proche dans l'esprit de ce que fait Lucid avec certaines options de ses logiciels d'optimisation, si ce n'est que Lucid pousse le système jusqu'à essayer de prédire quelles images pourront être sautées pour simplifier leur rendu au niveau du GPU et gagner en performances.

En ce qui nous concerne, il n'y a donc pas de vrai ou de faux triple buffering. Il n'y a qu'une méthode exploitée en pratique et elle est destinée à favoriser la régularité de l'affichage, la fluidité, en faisant un compromis au niveau de la latence. Une variante existe et déplace le compromis pour s'adapter aux très hauts fps mais n'est pas utilisée en pratique, posant plus de problème qu'elle n'en résout dans des conditions de jeu normales.


La synchronisation verticale dynamique
Une nouvelle fois c'est un même nom qui revient. En 2011, John Carmack avait fait du lobbying auprès des fabricants de GPU en leur demandant de donner accès aux développeurs à une gestion dynamique et automatique de la synchronisation verticale. Nvidia avait alors été le plus réactif et a intégré quelques temps après une option dédiée dans ses pilotes dénommées synchronisation verticale adaptative.

Cette option consiste à faire travailler le GPU et le moteur d'affichage en VSYNC ON quand le temps de rendu est inférieur à la durée d'un cycle d'affichage (le GPU tourne à plus de 60 fps en 60 Hz) et à passer automatiquement en VSYNC OFF quand il y est supérieur (le GPU tombe à moins de 60 fps). De quoi limiter le tearing du VSYNC OFF et éviter les grosses saccades ou chutes de performances du VSYNC ON. Il reste cependant un petit peu de tearing et quelques saccades lorsque les performances passent sous 60 fps.

C'est une nouvelle fois un compromis différent et non une solution miracle. Compromis qui nous semble cependant pertinent dans bien des cas pour améliorer le confort de jeu. A noter qu'utiliser un limiteur de performances, que ce soit à 59 ou 60 fps en 60 Hz VSYNC OFF, permet d'obtenir un résultat très proche de celui d'une synchronisation verticale dynamique.


Passer à 120 ou 144 Hz ?
Ce détail est souvent ignoré des joueurs, mais passer à un taux de rafraîchissement supérieur, par exemple 120 ou 144 Hz alors que les performances tournent entre 40 et 60 fps permet de limiter les défauts des modes VSYNC ON et OFF. Dans ce dernier cas, les raisons sont évidentes, le tearing apparaîtra moins souvent, les petites saccades seront quelque peu étouffées et la latence moyenne sera légèrement réduite.

En VSYNC ON, c'est un petit peu plus compliqué et l'avantage est lié au fait que plus de temps d'affichage intermédiaires vont être possibles :

60 Hz : 16.7 ms, 33.3 ms, 50 ms (60, 30, 20 fps)
120 Hz : 8.3 ms, 16.7 ms, 25 ms, 33.3 ms, 41.7 ms, 50 ms (120, 60, 40, 30, 24, 20 fps)
144 Hz : 6.9 ms, 13.9 ms, 20.8 ms, 27.8 ms, 34.7 ms, 41.7 ms, 48.6 ms (144, 72, 48, 36, 28.8, 24, 20.5 fps)

Dans notre exemple précédent, lorsqu'une image nécessite un temps de rendu de 18 ms sur un écran 60 Hz en VSYNC ON, l'image précédente doit être affichée pendant 33.3 ms, ce qui entraîne une saccade importante et augmente la latence de 15.3 ms. En 120/144 Hz, l'image précédente n'aurait dû être affichée que pendant 25/20.8 ms, avec une latence supplémentaire de 7/2.8 ms. De quoi l'atténuer significativement. Ce n'est pas le cas pour toutes les saccades mais statistiquement, ce sera en moyenne toujours mieux avec un taux de rafraîchissement supérieur.

A noter qu'en 120/144 Hz, le triple buffering profite de son côté d'une latence réduite au niveau de celle du double buffering en 60 Hz et la synchronisation verticale dynamique se comporte comme le mode VSYNC OFF vu le niveau de performances pris en exemple.
Vos réactions

Top articles