L'exécution de scripts est bloquée. De nombreuses fonctionnalités du site pourraient être manquantes. Dont un menu de navigation plutôt pratique.

A minima, voici les mentions légales.

Tuto n°02 : Synchronisation verticale

v11 -

Version Expresso : Tuto 02 - Synchronisation verticale (Expresso)

Introduction

Salut, c’est 3 potes !

Dans ce tuto, nous allons détailler le fonctionnement de la synchronisation verticale. Parce que pour choisir entre V-sync, Fast Sync, G-Sync et Freesync, il faut comprendre un minimum qu’est-c’qui s’passe. Un résumé rapide de tout ça se trouve dans le tuto n°1.

Glossaire et abréviations

Cas général sans synchronisation

Commençons par quelque chose de commençable : D’où vient l’image du jeu ? (sans rentrer dans les détails, faut pas déconner)

Commençons notre extraordinaire voyage avec la carte graphique, mère de toutes les images, pouponnière de texture et d’ombres, matriarche héroïque des projections polygonales et autres occlusions lumineuses. Dedans se trouve la mémoire vidéo (ou VRAM) qui sert de « frame buffer » (tampon de trame, ou mémoire d’image). Ce frame buffer est dans la majorité des cas divisé en 2 parties virtuellement distinctes ayant des fonctions différentes : back buffer et front buffer.

Schéma des buffers

Le back buffer sert de table de calcul pour le GPU, tandis que les données stockées dans le front buffer sont envoyées à l’écran pour afficher l’image. Pourquoi « virtuellement distinctes » ? Parce que c’est n’est qu’un seul et même composant électronique, seul le logiciel de la carte graphique attribue un rôle arbitraire à telle ou telle partie de la VRAM. D’ailleurs, à certains moments, les back buffer et front buffer « changent de place ». En réalité il ne se passe rien physiquement. C’est simplement le logiciel de la CG qui décide que les cellules mémoires qui endossaient le rôle du back buffer endossent maintenant celui du front buffer. Et inversement.
Dans un monde parfait, l’écran termine d’afficher son image, le front buffer (qui contenait les données destinées à l’écran) se vide, le back buffer (gorgé de données fraichement calculées par le CPU) « prend sa place », ces nouvelles données sont envoyées à l’écran et le GPU peut démarrer le calcul de l’image suivante.
Malheureusement nous ne sommes pas dans un monde parfait. La preuve en est avec ce tuto un peu naze écrit par un auteur vraiment pas ouf.

La plupart des écrans a un taux de rafraichissement fixe : 60Hz, 120Hz, 144Hz, … Un écran 60Hz, par exemple, affichera 60 images par seconde, soit une image toutes les 16,6666667 millisecondes. Cela signifie que le front buffer se vide toujours à la même vitesse. Cependant une carte graphique ne peut pas tenir ce rythme digne d’un coucou suisse. Suivant les scènes, certaines images prennent plus de temps que d’autres à être calculées, et donc le back buffer se remplit plus ou moins vite. On peut considérer deux cas de figure schématisés par cette jolie diapo made in NVIDIA :

Graphe Pas de synchronisation verticale
Crédit image : NVIDIA

1er cas : La carte graphique calcule plus vite ①

Le back buffer (vert) se remplit plus rapidement que le front buffer ne se vide (gris). Tant pis, les buffers sont inversés pour que le GPU puisse calculer une autre image. L’écran n’avait pas fini d’afficher son image et se retrouve avec des données d’une nouvelle image. Il arrête donc au milieu de la première et continue avec la deuxième. Littéralement. La démarcation entre les deux images peut être visible, on appelle cela un déchirement d’image, ou tearing.

2ème cas : La carte graphique calcule plus lentement ②

Le front buffer (gris) se vide plus rapidement que le back buffer (vert) ne se remplit. Contrairement au cas précédent, la carte graphique ne va pas inverser les buffers pour que l’écran affiche une image à moitié calculée. Les buffers restent à leur place et l’écran, n’ayant pas de nouvelles données, réaffiche la même image. On perd en fluidité, et ce phénomène ponctuel s’appelle une micro-saccade, ou stuttering. Ensuite, le GPU peut très bien avoir terminé son calcul, on a inversion des buffers et BIM re-tearing.

Et le tearing, ça ressemble à ça :

Exemple de tearing
Crédit image : hardware.fr

Sur ce screenshot, on voit bien que l’écran a commencé par afficher une image (1), puis en a rapidement reçu une nouvelle (2) et a donc continué avec. Mais il n’a même pas eu le temps de finir de l’afficher que la CG lui en avait expédiée une autre (3) ! Il est perdu le pauvre chou. Je te l’accorde, quand on ne fait pas attention le tearing peut être assez discret pour ne pas se faire remarquer. Mais maintenant tu y feras attention et tu ne le supporteras plus. De rien. Je suis là pour ça.

Là, tu peux te dire « Hey, et si la carte graphique elle attendait que l’écran ait terminé d’afficher son image pour lui en balancer une nouvelle ? ». Et je te répondrais que c’est une magnifique transition pour le point suivant.

Résumé

Pas de synchronisation verticale, ça signifie :

V-Sync : la synchronisation verticale de base

Le V-Sync, c’est une solution logicielle au problème de tearing. La carte graphique va laisser l’écran terminer l’affichage de son image avant d’inverser les buffers.

Reprenons nos deux cas précédents avec un petit schéma qui va bien :

Graphe V-Sync
Crédit image : NVIDIA

1er cas : La carte graphique calcule plus vite ①

Le back buffer (vert) se remplit plus rapidement que le front buffer ne se vide (gris). Néanmoins la CG attend sagement que l’écran ait terminé d’afficher son image avant d’inverser les buffers. Magnifique, pas de tearing.

2ème cas : La carte graphique calcule plus lentement ②

Le front buffer (gris) se vide plus rapidement que le back buffer (vert) ne se remplit. L’écran n’a aucun réglage particulier, donc il n’attend pas le GPU et redémarre son cycle avec la même image. Donc stuttering. Le GPU termine son calcul juste après, et on retombe dans le cas 1 mais avec une attente qui peut être beaucoup plus longue. On a alors un retard à l’affichage (ou lag) assez important, qui augmente l’input lag général.

Mais ça l’augmente comment l’input lag ? C’est vraiment handicapant ou est-ce du pinaillage que seuls les pro-gamers à l’œil affuté remarquent ? Eh ben devine quoi, il y a mec assez taré motivé pour mesurer l’input lag dans différentes situations.

Graphe Input lag V-Sync
Crédit image : Blurbusters

Les mesures ont été faites sur Overwatch avec un écran 240Hz bridé à différentes fréquences. On voit par exemple un input lag de 100ms pour un l’écran réglé à 60Hz. Évidemment, les écrans plus rapides (donc vidant leur front buffer plus rapidement) ont des input lag plus faibles avec le V-Sync activé.

Le V-Sync est donc une solution simple au tearing, mais qui montre ses faiblesses lorsque le GPU n’arrive pas à suivre la cadence de l’écran. Cela se traduit par du stuttering et un input lag élevé. On pourrait imaginer diminuer cette faiblesse en réduisant la période d’attente du GPU, lorsque le front buffer n’est pas encore vide. Et c’est ainsi que naquit le triple buffering. Allélouÿa. Enfin peut-être pas…

Résumé

Le V-Sync activé, ça signifie :

Triple buffering : la rustine du V-Sync

Le triple buffering, ou « tampon triple » dans la langue de Maître Gims, est une solution logicielle qui a pour but de diminuer le stuttering causé par le V-Sync. Son principe est simple : proposer un troisième buffer pour y stocker les données en attente.

Si on reprend nos deux cas avec un schéma tout nouveau tout beau tout chaud :

Graphe Triple buffering
Crédit image : NVIDIA

1er cas : La carte graphique calcule plus vite ①

Le back buffer (vert du haut) se remplit plus rapidement que le front buffer ne se vide (gris). Les données du back buffer passent alors dans le third buffer (vert du milieu) quand celui-ci est disponible, et le GPU peut démarrer un nouveau calcul. Lorsque l’écran a besoin de nouvelles données, il pioche dans le third buffer.

2ème cas : La carte graphique calcule plus lentement ②

Le front buffer (gris) se vide plus rapidement que le back buffer (vert du haut) ne se remplit. L’écran prend alors les données présentes dans le third buffer (vert du milieu). L’image calculée juste après est ensuite stockée dans le third buffer précédemment vidé.

Avec cette nouvelle technique, on réduit fortement le stuttering et son inconfort visuel. Cependant il y a systématiquement une image de décalage, du fait de son stockage dans le third buffer. Cela se traduit en pratique par un input lag beaucoup plus important.

Résumé

La mémoire à triple tampon activée, ça signifie :

Fast sync : V-Sync améliorée

Le Fast Sync, c’est une solution logicielle qui n’est dispo que sur les cartes NVIDIA à partir des GTX 9xx. Visuellement, il donne les mêmes résultats que le V-Sync mais en générant un input lag moins important. Je ne sais pas vraiment comment ça fonctionne, mais le gain est réel. La preuve en est avec notre testeur fou :

Graphe Input lag fast sync
Crédit image : Blurbusters

En comparant au graphe du V-Sync, on voit que l’input lag est plus que divisé par deux. Une petite remarque cependant : Plus le nombre de FPS est élevé (et au-dessus de la fréquence maximale de l’écran), moins le Fast sync est sensible au stuttering et à l’input lag. On le voit d’ailleurs entre un jeu à 300 FPS et un jeu à 58 FPS, l’input lag passe de 39 à 51 ms. Pour le stuttering, il va falloir croire notre Buster sur parole.

Résumé

Le Fast Sync peut être utilisé en remplacement du V-Sync avec une carte NVIDIA GTX 9xx et plus récente. Son activation signifie donc :

Variable Refresh Rate (VRR) : Le Saint Graal

Le VRR, c’est une solution matérielle à tous les problèmes. Sauf la calvitie. Là, faut simplement accepter son sort.
« Variable Refresh Rate » est le nom générique de la technologie de rafraichissement adaptatif des écrans, et est repris par une norme VESA, « Adaptive Sync », encore très peu adoptée. Actuellement on trouve deux déclinaisons commerciales du VRR : Freesync pour le système développé par AMD, et G-Sync pour le système développé par NVIDIA. Dans les deux cas le taux de rafraichissement de l’écran n’est plus fixe, il peut varier dans une certaines fourchette (en général entre 30Hz et la fréquence maximale de l’écran). Finalement, ça fonctionne à l’envers de ce qu’on a pu voir : la CG travaille à l’aveugle, et c’est l’écran qui s’occupe de réguler tout ça.

Promis, c’est la dernière propagande NVIDIA :

Graphe Triple buffering
Crédit image : NVIDIA

Le VRR tient tout son intérêt lorsque la CG n’arrive pas à suivre l’écran. Du coup, nos « 1er cas » et « 2ème cas » ont des conséquences un peu différentes.

1er cas : La carte graphique calcule plus vite ①

Le back buffer (vert du haut) se remplit plus rapidement que le front buffer ne se vide (gris). Ça signifie tout simplement que la CG a un nombre de FPS moyen supérieur ou proche de la fréquence maximale de l’écran, et donc que le VRR est inutile. Dans ce cas, ce système miraculeux se désactive. Ce qui devient gênant si les FPS retombent légèrement sous cette fréquence max, puis remontent, puis redescendent, …

2ème cas : La carte graphique calcule plus lentement ②

Le front buffer (gris) se vide plus rapidement que le back buffer (vert du haut) ne se remplit. C’est dans ce cas que le VRR tire son épingle du jeu. Le front buffer se vide, et l’écran ne recommence pas son cycle comme un gros teubé. Il attend patiemment que le back buffer se remplisse et qu’il prenne la place du front buffer. Pas de tearing, pas de stuttering, input lag minimal. Elle est pô belle la vie ?

Le 1er cas peut faire peur, mais il peut être évité assez simplement. En effet, en imposant une limite de FPS légèrement inférieure à la fréquence maximale de l’écran (par exemple à 141-142 FPS pour un écran 144Hz) on parvient à éviter la désactivation du VRR. Jetons un œil aux mesures de M. Blurbusters :

Graphe Input lag fast sync
Crédit image : Blurbusters

Sur un écran 60Hz avec G-Sync + V-Sync et une limite fixée à 300 FPS, le G-Sync se désactive forcément (avec une bonne CG) et on retrouve l’input lag du V-Sync. Avec une limite à 60 FPS, on ne bouge pas trop. Par contre avec une limite à 59 FPS ça devient intéressant : le G-Sync ne se désactive plus et on retrouve un input lag de 40ms. Remarquons en passant que baisser davantage cette limite ne change presque rien.

Cependant, cette limite ne doit pas être fixée n’importe comment. En faisant quelques tests sur Overwatch, on se rend compte que la limite de FPS in-game génère un input lag beaucoup moins élevé que la limite fixée par le logiciel NVIDIA Inspector. Gad’ moi don’ l’dessin qu’est d’ssous !

Graphe Input lag limiteur FPS Graphe Input lag limiteur FPS
Crédit images : Blurbusters

Ici on a un écran 144Hz dont la limite est fixée à 142 FPS pour garder le G-Sync (et 134 FPS pour vérifier que ça ne change rien). Les mesures ont été faites sur Overwatch avec 3 limiteurs de FPS : le jeu en lui-même, NVIDIA Inspector (NVI) et Riva Tuner Statistics Server (RTSS). On obtient ainsi des input lag de respectivement 23ms, 39ms et 28ms. Donc dans l’idéal, privilégie de limiter tes FPS directement avec le jeu. Au pire, vois avec Riva TSS.

Du coup, Freesync/G-Sync, kécécé la différence ?

Pour le moment en l’absence de l’adoption massive de l’Adaptive Sync, c’est l’bordel. NVIDIA a plutôt choisi la voie de la qualité contrôlée et onéreuse, tandis qu’AMD a préféré pencher vers un système plus souple et moins onéreux.
Les spécifications et l’inter-compatibilité changent en permanence, voilà où on en est actuellement :

Compatible
CG Nvidia
Compatible
CG AMD
Spécifications principales
G-Sync Compatible Oui 2020* VRR ratio > 2.4:1 (ex : 60-144 Hz)
Pas de flickering ou d’artefacts
G-Sync Oui 2020* + VRR dès 1 Hz
+ ULMB
G-Sync Ultimate Oui 2020* + « Lifelike » HDR
+ Très faible latence
Freesync ?** Oui VRR ratio non précisé
Faible latence
Freesync Premium ?** Oui + 120 Hz mini
+ LFC
Freesync Premium Pro ?** Oui + HDR
*Les écrans G-Sync sortis en 2020 devraient garantir le VRR aux CG AMD.
**Certains écrans Freesync sans mentions G-Sync peuvent quand même être compatibles, avec plus ou moins de réussite.

Attentions aux écrans sortis avant 2020. Les appellations G-Sync et Freesync (2) exigeaient des spécifications plus modestes.

En cas de non compatibilité l’écran affichera évidemment une image, mais tu n’auras pas accès au VRR.

Conclusion

Allez, j’arrête là et je récapitule, parce que je sens que ton p’tit crâne commence à chauffer. Si néanmoins ton cerveau est watercoolé à l’azote liquide (du coup ce serait nitrocoolé ?), tu peux aller creuser l’excellent article de Blurbuster sur ces technologies. Je n’ai repris que quelques graphes, il reste énormément d’infos dans les explications, et même dans les commentaires de l’article : https://www.blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/

Et pour finir, un tableau et un diagramme pour décompresser. Tu peux les imprimer et les scotcher sur ton écran pour ne rien oublier.

Utilisation Tearing Stuttering Input Lag
Aucune synchro Jeux réactifs Smiley non Smiley bof Smiley oui
V-Sync Jeux calmes ou
trop de tearing
Smiley oui Smiley non Smiley non
V-Sync +
Triple Buffering
Jeux calmes Smiley oui Smiley bof Smiley non
Fast Sync* Jeux réactifs
non haut niveau
Smiley oui Smiley bof Smiley bof
VRR** Tous jeux Smiley oui Smiley oui Smiley oui
*Nécessite une carte graphique compatible (GTX 9xx ou plus récente).
**Nécessite un écran compatible et un couple CG+écran compatible.
Diagramme de choix synchro verticale

A toi de choisir ! Même si c’est probable que ce soit plutôt ton porte-monnaie qui choisisse pour toi... Dans tous les cas, n’oublie pas de follow, et on te fera de gros bisous virtuels <3

Exosky pour C3POtes

N’oublie pas que c’est grâce à vos dons que nous pouvons continuer à proposer ces tutos de qualité inférieure ainsi qu’un fabuleux site web fait à la main, made in France et garanti sans pub. Soutiens-nous ! → https://streamlabs.com/c3potes/tip

Les avis/remarques/corrections/ajouts sont les bienvenus. Tu peux nous envoyer un p’tit message sur nos pages de réseaux sociaux et on essaiera de te répondre si on n’est pas trop occupés à se faire spawnkill par la team adverse.

Sources

https://www.blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/
https://www.hardware.fr/articles/914-3/rappel-v-sync-on-off-triple-buffering.html