Introduction

Aaaah les FPS dans les jeux vidéos, FRAMES PER SECOND ou IPS en français. On en entend parler partout, on en bouffe du FPS, on en VEUT, il m'en faut plus de 300 pour désamorcer la bombe dans CS GO NDKSFHDSKLGJHdlkjh

Oui du coup ça va être un article sur un aspect des jeux vidéos qui intéresse surtout les gens sur PC (dont tout le monde apprécie l'ouverture d'esprit) mais qui pourrait affecter les joueurs console dans un avenir proche.

Listons quelques vérités universelles sur les FPS:

• En avoir trop peu c'est triste
• En avoir trop c'est parfois triste aussi
• Avoir un taux de FPS qui change non stop et sur de grands intervales, c'est pas top

Sur console la question se pose pas trop parce que les options sont choisies pour vous, mais le PéCéiste se retrouve face à un foisonnant florilège d'options et combinaisons de technologies aux noms tous plus fleuris les uns que les autres, vendus comme essentiels pour améliorer son expérience de jeu et potentiellement empêcher sa carte graphique de réchauffer tout l'univers alors que peut-être c'était pas nécessaire.

Parcourons et définissons ensembles tous ces termes et technologies, en réfléchissant à quelles options activer dans les menus qui font peur sur pécé.

C'est quoi une FPS?

Non, sérieusement, c'est une bonne question.

Un jeu vidéo ça a toujours une structure plus ou moins similaire, qu'il s'agisse de Pacman en 1980 ou de HalfLife 3 en 2087, c'est un programme informatique d'ordinateur centré autour d'une boucle.

La BOUCLE est la répétition d'une certaine séquence d'instruction ad vitam eternam, parce que sinon ça veut dire qu'on est sorti de la boucle.

En fait, je dois vous avouer un truc d'ingénieur philosophe en programmation d'ordinateurs: tout programme qui ne s'arrête pas tout seul quand vous le lancez possède une boucle quelque part.

Par ex. le BLOC NOTE quand on l'ouvre, ben il se ferme pas tout seul. C'est parce qu'il y a une boucle événementielle qui attend que l'utilisateur saisisse du texte ou clique sur l'interface. On pourrait dire que la plupart des programmes modernes tournent autour d'une boucle bien que celle d'un jeu vidéo soit beaucoup plus complexe en terme d'actions utilisateur à vérifier et d'objets à modifier et dessiner, ...

J'ai embrouillé tout le monde, c'est pas grave.

Une boucle de jeu vidéo scrute aussi plusieurs événements, particulièrement quels contrôles de jeu ont été entrés (déplacer le joueur vers la droite, ...) mais son rôle le plus couteux est presque toujours celui de redessiner la scène de jeu.

Reprenons l'exemple de Pacman: ce jeu a un certain rythme fixe où l'image change pour montrer l'avancement de Pacman et des fantomes.

En réalité, tout le bourzdafgue est redessiné à chaque itération de la boucle et, comme ça se passe plusieurs fois par seconde, on a l'impression que ça bouge, comme quand on dessine une animation sur le coin d'un livre et qu'on passe rapidement toutes les pages: c'est une série d'images fixes qui passent à un certain rythme et donnent une impression de mouvement.

Nous les humains on aime bien avoir au moins 30 images par seconde (de préférence constantes) pour qu'un mouvement ait l'air plus ou moins naturel.

Chacune de ces images est normalement traitée par la boucle de jeu qui doit vérifier ce qui doit changer dans la scène suite à pleins de trucs:

• Actions du joueur
• Actions d'autres joueurs
• Actions d'éléments du jeu non contrôlés par le joueur (NPC, Bots, mobs, ...)
• Etat du moteur physique: il y a un rocher qui a été projeté qui est toujours en voyage et il faut simuler son mouvement avec des calculs de rocher qui tombe
• (Pré)Charger d'éventuels nouveaux éléments en mémoire
• Vérifier toutes sortes de conditions (est-ce que la nuit vient de tomber dans le jeu, est-ce que le tamagochi doit faire caca, est-ce que le joueur a gagné la partie, est-ce que le joueur a perdu la partie, est-ce que le joueur est inactif depuis un moment, est-ce qu'il serait pas temps de faire pleuvoir dans le jeu histoire que Link tombe de cette falaise que vous grimpez depuis 10 minutes, ...)

Ces opérations se passent dans le microprocesseur de l'ordinateur et sa mémoire vive. Ces deux éléments formant un couple inséparables - L'un ne sert à rien sans l'autre. C'est beau.

Quand la scène est prête, elle est passée à la carte graphique au travers de librairies partagées spécifiques (DirectX est l'une d'entre elles). Les scènes sont ensuite passées à la carte graphique ou au processeur graphique. A un truc graphique, quoi.

La carte graphique ou équivalent est spécialisée dans le traitement de scènes 3D et peut passer plusieurs parties de la scène en parallèle dans une énorme moulinette de filtres à appliquer sur l'image pour, entre autres, calculer la lumière et les ombres, ajouter des particules et effets, appliquer des textures sur les surfaces, ...

Le nombre de traitements réalisés par la carte graphique est BRUTAL et doit se faire le plus rapidement possible parce que si l'image 3D prend 4 secondes à être calculée, il y aura eu des centaines d'itérations de la boucle de jeu depuis et l'image 3D ne correspondera pas du tout à l'état actuel du jeu et puis surtout 1 image toutes les 4 secondes c'est pas assez pour donner une impression d'animation, c'est plutôt une présentation PowerPoint.

On touche déjà à une notion importante sur le sujet qui nous occupe: si la carte graphique n'arrive pas à produire suffisamment d'images à temps, la boucle de jeu doit attendre.

Dans un jeu complexe ça ne veut pas dire TOUT arrêter. Certains aspects du jeu peuvent continuer, au choix mais un rendu à la ramasse aura toujours des conséquences délétères communément appelées "lag" par les GameRZ.

C'est aussi une sitation dite de GPU bottleneck dit aussi "la carte graphique est le GOULOT d'ETRANGLEMENT" par les personnes de grande culture.

D'autres composants se font parfois attendre. Citons par exemple la couche réseau dans un jeu multijoueur, et l'effet est similaire sauf que c'est pas la faute de la carte graphique.

Le problème inverse est aussi possible: la carte graphique est au chômage parce que la boucle de jeu envoie trop peu de scènes 3D à calculer et on a moins de FPS que ce qu'on voudrais.

Ce phénomène est dû à: pourquoi y a autant de listes à puce dans cet article

• Une boucle de jeu foireuse, avec beaucoup trop de trucs à faire y compris des trucs lents par nature (attente réseau, stockage de masse, ...);
• Le processeur et sa mémoire qui n'arrivent pas à suivre parce que pas assez puissants pour la complexité de la boucle de jeu.

Parfois c'est les deux en même temps dans des proportions diverses et variées. Il est néanmoins courrant d'accuser le processeur souvent à juste titre puisqu'en théorie s'il était beaucoup plus balaise il pourrait compenser une boucle de jeu très inefficace.

On appelle dès lors très souvent cette situation un goulot d'étranglement au niveau du processeur ou une situation limitée par le processeur.

Les films sont à 24 images secondes donc faut pas plus, non?

Un bon vieux débat qui fait toujours plaiz: pourquoi il faut plus que 24 FPS pour un jeu vidéo? Les films sont en 24 images secondes et c'est OK, t'as vu Matrix ou quoi?

Filmer avec une camera va toujours produire un certain flou autour du mouvement (à moins d'avoir une camera qui capture 100000000 d'images secondes et d'avoir un écran capable d'afficher BEAUCOUP d'IPS) que vous pourrez constater si vous arrêtez un film sur image.

Déjà, les gens ont des drôles de tronches, ensuite les objets ou scènes en mouvement ont un flou directionnel naturel qui dépend de la vitesse relative, direction etc.je mets etc. parce que j'ai aucune idée de ce qu'il y a d'autre.

Si vous prenez une photo d'un objet en mouvement, vous verrez sans doute une certaine dose de flou aussi, sauf si l'obturation... Le temps de capturation photograhique (mon niveau de vocabulaire photographique est de 3 (sur 1000)) est très court. HE BIEN une camera c'est comme un appareil photo mais qui... Obture (??) un certain nombre de fois par seconde.

Ce flou permet à notre cerveau de naturellement coller une image à la suivante, en tant que suite logique et véritable scène de vie qui forment un tout.

Le cerveau ne voit pas les images individuelles avec toutes les parties "sales tronches", il digère toute la séquence comme un mouvement naturel qui aurait pu réellement se produire devant vos yeux.

Une boucle de jeu est au courant du mouvement des objets (même si c'est simulé par un modèle, je le rappelle au cas où). Néanmoins, ils sont dessinés à chaque image en tant que tels, comme s'il n'y avait pas de mouvement. Ils se retrouvent simplement à un autre endroit à l'image suivant.

Si vous arrêtez sur image un jeu vidéo (ça s'appelle un SCREENSHOT LOL) vous verrez que tout est bien propre et net (et les personnages ont une tronche qui fait pas trop peur sauf dans Morrowind), même si vous zoomez sur le ballon en mouvement dans Rocker League.

Pour rendre le mouvement plus naturel, on a ajouté un effet appelé "motion blur" qui est activé par défaut dans beaucoup de jeux vidéos. Sauf que ça rend pas le mouvement plus naturel parce que motion blur ne s'applique qu'au mouvement de la camera et pas des objets en mouvement à l'écran.

Du coup c'est complètement nul. Je comprends pas les gens qui jouent avec motion blur activé. Je peux même plus dire que je les juge pas parce que c'est pas vrai je les juge très fort.

Perso je désactive toujours immédiatement motion blur et d'ailleurs toutes les autres options qui flouttent des parties de l'image (simulation du focus d'une vraie camera) parce que je trouve pas ça naturel du tout dans un jeu.

Je peux investir un peu plus de générosité et avouer que le flou de mouvement rend plus acceptable des variations de taux de FPS qui sont souvent le symptôme d'un soucis de performance (et/ou d'un moteur de jeu tout pourri, comme d'hab)

Force est de constater que ces éléments sont très difficiles à simuler avec une suite d'images générée par ordinateur.

Les 24 FPS des films ne varient jamais. C'est précisément 24 FPS tout le temps, pendant tout le film, et ça aussi ça aide à apprécier le média.

Et puis, n'ignorons pas le pouvoir de l'habitude. Psychologiquement, c'est très puissant l'habitude. On pourrait facilement s'habituer à des films en 60 FPS, mais ça demanderait de nouvelles camera (beaucoup plus chères) et ça prendrait [...parti calculer...] 2,5 fois plus de place en prenant le risque que les gens trouvent ça bizarre, voire que certains en deviennent nauséeux et postent sur Twitter que c'est comme par hasard 6 ans après un vaccin covid.

Vous l'aurez peut-être compris, ce choix de 24 FPS est vaguement arbitraire, basé sur des mesures moyennes et estimées de persistence rétinienne histoire de trouver un minimum d'images qui fonctionne pour économiser du FRIC.

Il est souvent admis que 24 FPS avec flou de mouvement naturel est acceptable, mais qu'il faut au moins 60 FPS pour une animation convainquante sans ce flou de mouvement naturel.

Ou alors, 30 FPS. La Nintendo Switch n'est pas assez balaise pour 60 FPS dans beaucoup de jeux et il y a tout à fait moyen de jouer des centaines d'heures à 30 FPS (même si je trouve pas ça génial hein, soyons honnêtes ; une Switch consomme à peine 15W on va pas être difficiles).

Hep Hep, attends une minute! Les films d'animation genre Pixar, ils sont générés image par image par des ordinateurs, sortent en 24 FPS et ça parait naturel comme un autre film. Comment que possible??

Les films d'animation utilisent des technologies complexes pour simuler le flou de mouvement naturel, particulièrement dès qu'il y a un mouvement rapide à l'écran.

Cet article parle de "smear", un porte-manteau de technologies qui simulent du flou et de la distorsion de mouvement, y compris pour des films d'animation "classiques" (pas en 3D).

Les films d'animation sont très différents d'un jeu en cela qu'il est tout à fait acceptable de prendre des heures pour générer 1 FPS de film d'animation et que toutes les scènes qui suivent et précèdent la scène en cours sont connues, ouvrant une crapitude de possibilités d'interpolation temporelle.

Dans un jeu, vous pouvez déplacer vous-même la camera ainsi que votre personnage et interagir avec le reste du jeu d'une manière difficile à prédire. J'aurais bien dit impossible mais avec ce qu'on fait en intelligence artificelle de nos jours je suis plus sûr de rien.

D'ailleurs, il existe déjà des techniques "qui devinent l'avenir" comme DLSS (exclusivité Nvidia malheureusement) et peuvent en théorie réaliser une interpolation temporelle par prédiction.

Mais on s'égare.

De toutes façons on peut voir que 20 images par secondes lol

Les gens qui disent ça s'en réfèrent (souvent sans le savoir) au phénomène de persistence rétinienne qui dit que la rétine imprime toujours les images pendant un certain temps minimum.

Vous pouvez le tester en regarder un truc puis **EN FERMANT VITE LES PAUPIERES**, vous voyez encore un petit peu le truc pendant quelque temps.

Ce phénomène prouve que le combiné yeux-cerveau met un peu de temps à réagir et ne peut pas modifier instantanément ce qui est imprimé sur la rétine à un instant donné.

Et genre c'est surprenant ça? Comme si il existait beaucoup de réalités physiques qui sont capables de changer instantanément. Je pense qu'il en existe aucune mais cet article n'est pas (encore) à propos de science et philo.

Je pense que la véritable explication moderne indique que les cônes et bâtonnets ne sont pas disponibles tout de suite pour réactivation et que le nerfs optique continue de transmettre à peu près la même info (et donc la même image) le temps que la biochimie de l'oeil soit prête pour ramasser plus d'information visuelle.

De vieux travaux scientifiques semblaient montrer que la persistence d'une image dure environ 50 millisecondes et que donc on ne peut voir que 20 images par seconde.

C'est cool sauf qu'on passe à côté de toutes sortes d'effets psychologiques ou, en résumé, de filtres implicites au combiné indisociable yeux-cerveau. Jusqu'à ce qu'on puisse brancher des yeux humains sur un robot. Et encore. On passe aussi à côté de quel type d'image il s'agit, à quelle luminosité, modifiée selon quel mécanisme (écran, objet réel en mouvement ?).

De fait, la vieille théorie de la persistence rétinienne est contestée.

Ce dont on est plus ou moins certains, c'est qu'à une fréquence faible de 10-16 images par secondes sur un projecteur ou écran, les gens sont assez d'accord qu'il y a un clignotement désagréable.

Ce qu'il se passe à des plus hautes fréquences n'est pas si simple car même si les yeux sont incapables de voir individuellement toutes ces images, le cerveau reçoit une claire impression de mouvement qui est tout aussi importante, son interprétation, quoi.

De la même manière que nos oreilles ne traduisent pas une vérité acoustique absolue en raison de la réponse en fréquence pas complète et pas linéaire additionnée des effets psycho-acoustiques, notre vision n'est pas nécessairement un reflet exact de la réalité non plus.

C'était pas non plus un secret pour les plus vieux d'entre vous (désolé) qu'une fréquence de rafraichissement de 60 Hz (= 60 images/seconde) sur un écran à tube affichait un scintillement dérangeant, surtout dans la vision périphérique, mais pas un écran LCD de 60 Hz.

Ils affichent tous les deux 60 images par seconde mais d'une manière totalement différente. Le balayage de l'écran à tube est beaucoup plus distrayant pour le cerveau qui arrive à capter la variation de lumière du rafraichissement (alors que ça se passe très rapidement).

En résumé: Le combiné yeux-cerveau ne peut pas percevoir beaucoup plus que ~20 images individuelles par seconde. Par contre, avoir davantage d'images par second change sa perception du mouvement et invite une interprétation plus fluide de ce mouvement.

Evidemment il y a une limite à ça, je pense que si vous faites un blind test à quelqu'un sur un jeu à 100 FPS vs 200 FPS sur un écran capable d'afficher ces fréquences, beaucoup de gens ne vont pas voir la différence.

Par contre, montrez un jeu en 30 FPS, puis le même à 100 FPS, je pense que la majorité des gens qui ont l'habitude de ce type de media vont très clairement voir la différence. Je vous invite à réaliser cette expérience scientifique chez vous ou juste de me croire si vous avez pas d'amis.

Petite précision importante: ça veut pas dire que 30 ou 60 FPS c'est injouable. C'est tout à fait jouable, surtout si ce taux d'images par second reste plus ou moins constant.

Par ailleurs, si vous êtes capables de remarquer la différence c'est qu'il y a beaucoup de chances que vous préfériez avoir plus de FPS si vous aviez le choix et que votre écran était capable de les afficher.

Après tout j'ai passé moulte kilogrammes d'heures sur Zelda Breath of the Wild, qui est en 30 images/seconde, et j'étais pas en train de pleurer. Sauf quand il se mettait à pleuvoir mais bon.

Ordinateurs et écrans: les bases

Bon où est-ce que j'en étais moi? Ah oui! C'est quoi vsync, gsync, rsync, et toussa?

Je crains de devoir passer encore deux ou trois lignes pour expliquer deux ou trois concepts et peut-être que cet article sera un peu plus long que court. Je suis très rigolo.

La carte graphique

De nos jours tout ce qui est un petit peu complexe est dessiné par la carte graphique, même en 2D.

La carte graphique possède la logique qui permet de parler à des écrans (tout de même assez important je crois) mais la majorité de la surface de sa puce sert à rapidement calculer des images en 3D.

Son élément principal est le GPU, un type de processeur spécialisé qui se trouve quelque part plus ou moins au centre de la carte. Le reste de la carte graphique comprend une mémoire dédiée au GPU et les circuits d'alimentation et de régulation de tension du GPU, ainsi que des éléments de filtrage divers.

Quand je parle de calculer les scènes rapidement, il faudrait pouvoir au minimum sortir une image de la scène 3D toutes les 16 millisecondes, ce qui nous ferait 60 FPS.

C'est très rapide, on peut pas se permettre de perdre du temps dans le calcul de ces images qu'on appelle parfois le 3D pipeline (parce que c'est un peu comme suivre une série de tubes) et qui affiche un haut niveau de parallélisme.

C'est aussi pour ça qu'on parle de "3D temps réel" (enfin, on en parlait surtout quand j'étais JEUNE tousse tousse) parce que les images sont calculées en nombre et très rapidement.

Pas question de prendre des minutes voire des heures pour dessiner une image — Ce qui est pourtant acceptable pour générer un modèle 3D d'architecture ou une image d'un film d'animation — Ces domaines d'application ne sont pas de la 3D temps réel.

En gros résumé, le processeur de l'ordinateur donne à la carte graphique les charactéristiques d'un espace 3D avec des points placés à différents endroits de l'espace entre lesquels il s'agit de dresser des objets 3D qui seront en pratique constituées d'une grande quantité de petits triangles — Parce qu'on a des algorithmes très rapides pour les calculs géométriques à base de triangles et rappelez-vous que j'ai dit que la vitesse était primordiale.

Il fournit en outre la position de la fameuse camera, le point de vue duquel il faudra générer une image 2D de la scène pour l'envoyer à l'écran (qui affiche des images en 2D, petit spoiler) et les informations sur l'éclairage de la scène géré de manière simplifiée et par approximation, de nouveau pour aller vite.

Le GPU va passer tout ça dans plusieurs moulinettes pour ajouter des textures, appliquer le modèle d'éclairage (ainsi que les ombres, calculs de reflets, etc.), appliquer une série de filtres programmables puis transformer l'espace 3D en 2D pour créer une image que l'écran peut afficher qui est fait un genre de photo de la scène qui vient d'être calculée.

Selon la position de la camera et l'information de profondeur, la carte graphique pourra encore gagner du temps en évitant de dessiner des objets qui sont de toutes façons hors champ ou cachés derrière un autre objet (qui n'est pas translucide).

Les cartes graphiques modernes sont également capables d'accélerer du calcul 2D (une chatouille par rapport à la 3D), de décoder et parfois aussi encoder certains codecs vidéo de manière matérielle (= très efficace mais peu flexible).

Vos vidéos Youtube de Mr Beast sont très probablement décodées par la carte ou puce graphique.

L'objet ressemble normalement à ça (la carte pas Mr Beast):

Ou encore ça:

Voire ceci:

Le GPU peut aussi se retrouver intégré à une autre puce, comme le processeur.

Toutes les consoles modernes sont basées sur ce types de puces à haute intégration contenant une partie processeur générique et une partie processeur graphique, le tout dans une seule puce. Par conséquent, ils n'ont pas de carte graphique discrète mais il y a tout de même bien un GPU quelque part.

Certains processeurs pour ordinateur embarquent aussi une de ces puces graphiques, bien qu'il soit préférable de la supplanter par une réelle carte graphique séparée si on veut sérieusement jouer à des jeux.

Les performances des puces graphiques sont parfois mesurées en TERAFLOPS, principalement parce que c'est très rigolo à prononcer.

La raison secondaire découle des calculs de positions et des transformations géométriques en espace 3D où on utilise des valeurs en VIRGULE FLOTTANTE et TERAFLOPS signifie "billions d'opérations en virgule flottante par seconde" ou GIGAFLOPS (le même mais en milliards) pour les processeurs graphiques FAIBLES.

Quoi? Vous voulez vraiment savoir ce que c'est que cette histoire de flottaison de virgule? Vous croyez qu'il est pas déjà assez long cet article?

Bon allez, je me sacrifie pour une fois.

Je pense qu'on avait déjà établi que tout se passe en binaire dans un ordinateur. Absolument tout. Représenter un nombre entier comme 42 en binaire c'est assez simple: on prend une case mémoire suffisamment grande, et on y bourre le nombre transformé en binaire: 101010.

Reste plus qu'à bourrer des 0 devant ou derrière pour compléter une case mémoire de 8 octets parce que c'est important de toujours travailler avec des cases de tailles bien connues sinon c'est impossible de savoir ce que réprésente tout ce gros tas de bits en mémoire (rigolez pas c'est sérieux comme sujet). Et oui je sais que certains systèmes enregistrent tout à l'envers mais je pensais que c'était déjà assez compliqué comme ça.

Maintenant, comment que-je pourrais enregistrer le nombre 40,3399 en binaire?

Ah! C'est déjà une autre affaire. Même si vous êtes un petit malin et que vous vous dites qu'il suffit d'enregistrer la partie entière (40) dans une case, puis la partie décimale (3399) dans une autre, puis la position de la virgule (EN 3EME POSITION LOL) dans encore une autre case, vous êtes assez proches de la vérité.

N'empêche, il faut encore réfléchir à comment goupiller tout ça pour pouvoir réaliser des calculs avec ces nombres à virgule et leur représentation en binaire. Déjà en tant qu'humain c'est lourdingue les opérations avec des virgules et tout le monde sort sa calculatrice.

Ben en fait, c'est pas simple pour un ordinateur non plus et les "opérations en virgule flottante" (LES FLOPS) prennent plus de temps que des opérations sur des entiers. Je pourrais parler de JavaScript comme je le fais dans tous mes articles à ce moment précis parce que ce langage traite tous les nombres comme des nombres à virgule flottante et du coup doit les convertir régulièrement quand il s'agit d'entiers pour accélérer le calcul ET PROUT j'ai encore réussi à parler de JavaScript je suis tellement désolé....

S'il y a des enthousiastes de maths qui me lisent, peut-être se souviennent-ils des calculs matriciels, en particulier les produits de matrices.

Beaucoup de transformations réalisées par les GPU sont des produits de matrices de coordonnées 3D qui sont des chiffres à virgule.

Celà étant, comparer les FLOPS de différents GPU n'est pas vraiment une valeur sûre. Déjà parce que ces chiffres sont publiés par le fabriquant qui les a calculés dans des conditions particulières mais aussi et surtout parce que les performances graphiques font intervenir d'autres éléments que la performance pure en virgule flottante, comme par exemple la bande passante mémoire.

A quoi ça sert d'avoir tout un tas de FLOPS pour calculer l'éclairage d'un sac de patate dans un jeu si ça prend des plombes pour appliquer une texture de sac à patate sur le sac à patate? Ben ouais.

Du coup comparer ses FLOPS c'est un peu comme dire que son papa est policier, c'est cool mais on s'en fout. Sauf si c'est pour se moquer des FLOPS de la Wii par exemple.

Les cartes graphiques pour enthousiastes sont presque toujours le composant le plus gourmand en énergie de tout l'ordinateur. Et de loin.

Elles répondent aux mêmes réalités que les microprocesseurs: si on ne les utilise pas au maximum, leur consommation baisse, et comme leur consommation est presque entièrement dissipée en chaleur, les ventilateurs tournent moins vite et tout le monde est content.

L'Input Lag

Dit aussi, retard à l'entrée... Où "entrée" signifie donner des instructions à l'ordinateur par le biais d'un clavier, souris, contrôleur, volant, ...

On a déjà défini le game loop ou la boucle de jeu plus haut en tant que principe général, et vous vous souvenez certainement qu'une des étapes de la boucle consiste à lire les entrées utilisateur et décider de leur effet sur l'état du jeu (autre concept dont j'aurais peut-être dû parler mais je suis sûr que vous comprenez INTUITIVEMENT de quoi il s'agit).

Lire les entrées doit forcément se produire avant de balancer une nouvelle image à l'écran, et c'est là une partie de l'input lag: le temps qu'il faut pour traiter les entrées et gérer le reste de la boucle qui précède le moment où nous pourrons voir l'effet de nos entrées à l'écran.

Par exemple, dans un jeu AVEC DES FLINGUES, je click gauche, je m'attends à ce que mon personnage tire dans pas trop longtemps. Ce "pas trop longtemps", c'est l'input lag.

Outre le retard dans la boucle de jeu, il y a aussi le temps qu'il faut pour que le signal puisse être généré par l'appareil d'entrée et arriver physiquement à l'ordinateur et le temps du reste de la boucle de jeu comme par exemple la génération d'une scène 3D par une carte graphique.

On pourrait déjà creuser un peu le concept en parlant de manières de le réduire selon le type de contrôleur, particulièrement pour les souris. Je vais laisser ça pour une autre fois et on va se concentrer sur l'input lag engrangé par la génération d'images au niveau de la carte graphique et le/les écrans qui sont connectés dessus.

Avoir trop d'input lag dans un jeu multijoueur peut résulter en un adversaire tirant le premier alors que vous aviez cliqué avant lui dans l'espace-temps de la réalité. Exactement comme Han Solo (?).

C'est évidemment difficile (impossible) de savoir à combien d'injustices d'input lag on a pu être confronté, surtout qu'il y a encore le réseau (les internetes) dont on a pas parlé dans cette affaire.

Des sources parlent cependant de différences d'input lag de 50ms dans certaines circonstances dont nous discuterons peut-être sûrement dans cet article. Pour comparaison, le temps de réaction des humains est quelque part entre 150 et 250ms.

Notons déjà une vérité absolute à retenir: l'input lag baisse si les FPS calculées par le jeu augmentent. Ben si, c'est logique, si le temps entre deux images baisse, le temps entre une action de votre part sur un contrôleur et l'affichage de son résultat baisse aussi.

Pilotes et API graphique

Le processeur de l'ordinateur (et sa mémoire — j'ai-t-y pas déjà dit qu'ils étaient inséparables?) est l'organe sur lequel tournent réellement les programmes, y compris l'OS.

Sur un ordinateur de type PC, les systèmes d'exploitation créent une séparation de sécurité entre le mode noyau et le mode utilisateur.

Les programmes tournent en mode utilisateur et n'ont pas directement accès au matériel, par sécurité.

C'est l'une des plus importantes différences avec une console de jeu qui n'a pas vraiment de mode noyau, le jeu tourne en mode noyau et peut directement parler au matériel d'une manière propre à la console.

Sur un PC, il faut utiliser des fonctions spéciales liées à l'OS qu'on appelle les appels système on les appelle appels? Tu vas laisser ça comme ça?

Les appels système provoquent un basculement en mode noyau puis l'OS exécute l'opération demandée par l'application utilisateur. Un exemple d'opération mode noyau est "écrire un fichier". Parler à la carte graphique demande aussi le mode noyau.

Les pièces de programme permettant au système d'exploitation de parler au matériel s'appellent les pilotes, c'est un vieux concept dont on s'inquiète relativement peu aujourd'hui pourtant c'était un sacré sujet de conversation à l'époque de Windows 95... Si vous aviez des amis bizarres. Comme moi.

Les pilotes de carte graphiques ou GPU intégrés sont très complexes, ils doivent absolument être le plus rapide possible tout en autorisant une compatibilité avec d'anciennes et nouvelles méthodes de dessin de scènes 3D, proposer des éléments programmables dans le 3D pipeline et tenir compte de cas particuliers de jeux qui font tout planter ou qui tournent trop lentement pour une raison ou une autre.

Pour rendre tout ça un peu plus simple, on parle au pilote au travers d'une librairie partagée que les programmeurs peuvent facilement réutiliser: c'est l'API graphique.

Sous Windows la plus connue est Direct3D, aujourd'hui à la version 12.

Il y en a d'autres comme OpenGL ou Vulkan.

Par soucis de performance, il y a un couplage assez étroit entre API graphique 🠲 Pilote 🠲 Matériel (GPU) où les concepteurs de chaque pièce doivent se mettre d'accord sur le futur de la programmation graphique sur ordinateur (qui se traduit aussi sur console de nos jours).

En pratique et à moins d'être sous Linux (mes condoléances) le pilote est écrit par le vendeur du matériel. Si vous avez une carte graphique Nvidia, vous allez devoir télécharger et installer le pilote graphique Nvidia qui va bien mais vous savez déjà tout ça n'est-ce pas?.

Caractéristiques de l'écran

L'écran, c'est important.

Sans lui, ben on voit rien.

Je vais pas décrire toutes les technologies d'écran (je vous promet) parce que le plus important à savoir réside dans ce que le contrôleur d'affichage (évoqué dans la section "carte graphique") envoie à tous les types d'écrans confondus: une image matricielle.

On l'appelle aussi bitmap en anglais, terme que certains reconnaîtrons peut-être comme un format d'image de l'ancien temps.

En fait c'est pas un format d'ancien temps, l'idée du bitmap est ce qui est communiqué aux écrans pour affichage et la forme de base d'une image telle que traitée sur Photoshop, par exemple.

Les formats d'image PNG ou JPG encodent les mêmes images matricielles sauf qu'elles sont compresséees et requièrent une moulinette de décompression avant de devenir un bon vieux bitmap.

Ce tout dernier étant un tableau (une grille?) de pixels, eux-mêmes des éléments de données qui représentent chacun la combinaison de trois composantes de couleurs, le rouge, vert, et bleu.

Bien entendu, tout ça est en binaire, chaque pixel doit être strictement formé de la même manière et représenter le même nombre de bits, histoire que l'on puisse les distinguer les uns des autres.

Les couleurs sont la plupart du temps représentés par trois groupes de 8 bits, soit 24 bits au total.

Avec 8 bits on peut coder de 0 à 255 en décimal, ce qui nous fait 16 777 215 possibiltés de couleurs en combinant ces trois valeurs.

La technologie HDR est sortie de nulle part relativement récemment et utilise 10 (voire 12) bits par couleur au lieu de 8.

On va pas parler de la quantité de couleurs que peut distinguer un oeil humain parce que c'est encore tout un autre débat que je vous laisse volontier comme devoir de vacances.

L'image sous forme de tableau de pixels peut être décomposée en lignes et colonnes qui sont la première caractéristique importante de l'écran: la résolution.

La notion de résolution est plutôt évidente pour les écrans LCD, OLED, etc. Puisqu'ils possèdent physiquement trois ou quatre cellules lumineuses par pixel: une par couleur (et parfois une en plus pour faire plus lumineux).

Un écran LCD prévu pour une résolution de 1920x1080 est incapable de produire une image en 2560x1440, il n'a pas assez de cellules lumineuses. Alors, l'ordinateur pourrait appliquer un traitement sur l'image pour la transformer en image 1920x1080 mais la plupart des écrans sont incapables de réaliser eux-mêmes ce type d'opération (certains projecteurs le font, soit dit en passant).

Par contre, les écrans sont presque toujours capables d'afficher des résolutions inférieures à leur nombre de cellules, parce que c'est plus simple de retirer des pixels que de devoir en inventer.

La résolution est parfois écrite en "Megapixels", surtout pour les appareils photos numériques. Il suffit de multiplier les lignes par les colonnes de la résolution de l'écran pour trouver la valeur en megapixels (millions de pixels).

La taille du tableau de bits qui représente l'image à afficher à l'écran varie avec la résolution et la profondeur de couleur. De manière la plus simple possible, pour une profondeur de couleur 24 bits:

S = (H x V x 24) / 8

Où:

• S est la taille du bitmap en octets;
• H et V sont les dimensions horizontales et verticales en pixels (la résolution, quoi).

Non compressée, une image 4k prend à peu près 24 MO. A l'heure d'aujourd'hui ça a l'air ridicule mais fût un temps où 8 à 16 MO de mémoire c'était la norme, et c'était pas y a si longtemps.

L'autre caractéristique la plus importante des écrans est la fréquence de rafraichissement verticale que je vais appeler V pour la suite de cet article, parce qu'on va beaucoup en parler.

L'image à afficher ne peut pas être envoyée instantanément à l'écran, le contrôleur d'affichage va lire l'image à afficher sous forme de bitmap de haut en bas et gauche à droite — C'est à dire qu'on affiche la première rangée de pixels en partant du haut, plus la seconde, etc. Jusqu'à la dernière tout en bas de l'écran.

L'affichage est rapide mais pas instantané.

S'additionnent:

• Le temps nécessaire à afficher la totalité d'une image;
• Une petite pause entre deux images (héritages de l'époque des écrans à tube);
• Le micro-délai ajouté par le contrôleur d'affichage et l'accès à l'emplacement mémoire où se trouve l'image à afficher.

Ce délai rentre tranquillement plusieurs fois dans une seule seconde, au moins 60 fois par seconde pour les écrans LCD modernes.

L'unité de système international d'événements par seconde (= fréquence d'occurence) est le hz (pour Hertz).

La fréquence de rafraichissement vertical s'exprime par conséquent en Hz, vous pouvez trouver le V maximum supporté par un écran dans ses caractéristiques techniques.

Cette valeur peut dépendre de la résolution pour plusieurs raisons, la principale étant qu'envoyer 120 images par secondes de 24 MO ça prend beaucoup plus de bande passante (genre il faut UN PLUS GROS TUUUUBE) qu'envoyer 30 images par seconde de 2.3 MO.

Pour tirer le max de son écran, il est parfois nécessaire de s'équiper d'un cable répondant à une norme particulière.

Il existe effectivement plusieurs versions de ces deux connectiques:

Utiliser un cable DisplayPort permet de s'affrachir de davantage de variables qui s'introduisent avec l'usage du HDMI.

Le cable DisplayPort de base supporte déjà une résolution 4k (3840x2160) en 30 images par seconde, ce qui suffit déjà plus que largement si votre écran n'est pas un écran 4k. Sinon, il existe des cables DisplayPort à plus haut débit mais vous devez alors vérifier qu'ils sont supportés par votre écran et votre carte graphique.

Pour HDMI, vous devrez d'emblée vérifier les versions d'HDMI supportées par votre écran et votre carte graphique et choisir un cable qui correspond à la version la plus haute en dénominateur commun de ces deux éléments.

J'ai parlé des couleurs "HDR" plus haut, si votre écran est capable de HDR vous devez vérifier que le cable l'est aussi étant donné qu'augmenter la profondeur de couleur augmente le nombre d'octets par pixel et donc la bande passante de manière significative.

Le processeur de traitement interne à l'écran n'est parfois pas capable de gérer des bandes passantes élevées non plus, indépendamment du cable utilisé.

Pour des raisons que j'ignore et qui sont certainement aussi intéressantes qu'un exposé de 80 pages sur le "wokisme" (SARCASM), les télévisions ne proposent générallement que des ports HDMI et aucun DisplayPort. La plupart des écrans d'ordinateur proposent au moins un DisplayPort.

Je résume les deux caractéristiques principales:

• La résolution — Largeur du rectangle 2D qui représente l'image à afficher en pixels — Chaque pixel est caractérisé par sa couleur et sa position dans le rectangle;
• La fréquence de rafaichissement vertical — Ci-après abrégée V; L'écran re-dessine entièrement l'image qu'il affiche de haut en bas et gauche à droite un certain nombre fixe de fois par seconde: c'est la fréquence de rafraichissement vertical.

Peut-être que ces deux lignes de résumé auraient pu remplacer toute cette section. Trop tard.

En prix de consolation, je citerai un site connu qui détermine automatiquement la fréquence de rafraichissement effective de votre écran: https://www.testufo.com/

Les Framebuffers

J'ai pas réussi à traduire le terme en Français. Même sur Wikipedia ils ont abandonné, ils citent juste "tampon de trame" ou "mémoire d'image" en rougissant de honte au début de l'article.

Appelons un framebuffer framebuffer, en un mot comme des vrais ingénieurs en philosophie de la robotique transhumaine.

Comme expliqué plus haut, le contrôleur d'affichage envoie une image 2D à l'écran sous forme d'un tableau de pixels.

OK mais il est où qu'il est ce tableau de pixels?

Le contrôleur d'affichage va toujours le chercher exactement au même endroit: une région fixe de la mémoire vidéo (la mémoire dédiée du GPU dite aussi VRAM) appelée le frontbuffer, dont la taille utile dépend bien évidemment de la résolution et la profondeur de couleur en cours d'utilisation.

Le frontbuffer est le framebuffer qui contient l'image que l'écran doit afficher.

Le contrôleur d'affichage et l'écran s'en balancent totalement les transistors de ce qui change ou pas dans cette zone mémoire et quand ou comment c'est modifié, il lit simplement le contenu de haut en bas et gauche à droite à chaque rafraichissement vertical de l'écran, sans juger, sans discuter et sans rien modifier, et on va toujours le chercher au même endroit: dans le frontbuffer. Facile.

Le plus simple serait de modifier le frontbuffer en temps réel dès que la carte graphique a une image 2D qui est prête pour affichage.

Néanmoins, que se passe-t-il si le contrôleur d'affichage (et donc l'écran) est toujours en train de lire le frontbuffer alors que la carte graphique écrit dedans?

Tout simplement, on aura un morceau de l'écran avec des pixels de l'ancienne image (forcément au dessus puisqu'on lit de haut en bas) et un autre morceau avec des pixels de la nouvelle, voire de plusieurs nouvelles images si la carte graphique arrive à en sortir plusieurs sur l'intervalle de rafraichissement de l'écran.

Le frontbuffer est une constante en terme de technologie graphique, il n'y en a qu'un seul et c'est là que l'écran récupère l'image 2D qu'il doit afficher.

Nous verrons plus tard qu'il est courant d'utiliser d'autres framebuffers secondaires pour bien temporiser les images et que les contrôleurs d'écran modernes peuvent utiliser un pointeur comme frontbuffer.

Si vous n'avez jamais fait de C/C++ ou Rust ou autre langage système vous savez peut-être pas ce que c'est un pointeur et c'est pas grave, gardez votre innocence je vous en supplie.

Le tearing / déchirement

Bon, venons-en au phénomène indésirable principal. Lentement et avec amour.

Double Buffering

Sur toutes les plateformes graphiques modernes et même beaucoup d'anciennes, on ajoute au moins un autre framebuffer au frontbuffer (défini juste au dessus): le backbuffer.

Dans cette configuration, le GPU dessine toujours et uniquement dans le backbuffer, tandis que le contrôleur d'écran lit le frontbuffer (comme d'hab, il change rien lui).

Quand une image est prête dans le backbuffer, le GPU bascule les deux framebuffers de sorte que les données du backbuffer se retrouvent dans le frontbuffer.

L'opération peut être réalisée de plusieurs manières:

• Une bonne grosse copie — On copie tout le contenu d'un buffer dans l'autre, de bit à bit, ce qui permet de retrouver l'image que l'on vient de dessiner dans le backbuffer, puisqu'on a juste copié le backbuffer on l'a pas effacé ou modifié;
• Un échange de pointeurs mémoire — Plus rapide que la copie, surtout avec un gros tas de FPS: Le GPU et le contrôleur d'écran lisent d'abord une case mémoire où se trouve l'adresse mémoire de leur framebuffer respectif, puis peuvent aller consulter le dit framebuffer; Il est possible de juste échanger ces adresses mémoire et l'ancien backbuffer devient frontbuffer et vice-versa, mais rien n'a été copié.Si vous avez rien capté c'est pas grave.

Dans le premier cas, l'image que l'on vient de dessiner est toujours dans le backbuffer, ce qui peut-être intéressant pour certains cas où on compose sur la dernière image.

Par exemple, je sors cet exemple de ma raie mais imaginez une interface graphique avec une fenêtre d'explorateur de fichier ouverte. Si je déplace cette fenêtre, la majorité de l'image que je venais de larguer dans le backbuffer n'a pas changé, c'est juste le rectangle où se trouve la fenêtre déplacée qui a changé (bon et peut-être l'horloge en bas à droite, ARRETEZ DE CHIPOTER SvP), je pourrais dès lors gagner du temps en ne calculant que ce rectangle.

Le second cas, parfois appelé buffer flip, pourrait me permettre de trouver ce qui était dans le frontbuffer juste avant sauf que, pas toujours.

Je vous ai concocté un petit récit en deux étapes rassemblant quelques concepts précités:

Petit zoom des familles:

Sur le schéma, l'écran n'a pas terminé son balayage vertical, une nouvelle image est déjà prête dans le backbuffer et me rappelle d'ailleurs quelque chose.

J'ai vaguement touché plus haut que beaucoup d'implémentations utilisent plus qu'un backbuffer et ça devient impossible de garantir ce que l'on retrouve dans le buffer où le GPU est censé dessiner dans ce cas.

Traditionnellement, avoir 1 frontbuffer + 1 backbuffer s'appelle double buffering, parce qu'il y a deux framebuffers. Facile.

Désynchronisation

J'ai le droit de le spoil tout de suite: le tearing (déchirure dans l'image en mouvement) se produit quand le backbuffer est basculé en frontbuffer alors que le contrôleur d'écran est toujours en train de lire et envoyer à l'écran le contenu du frontbuffer.

Imaginons un cas simple de double buffering parce que de toutes façons le problème est le même avec d'autres dispositions de framebuffers:

1. L'écran est en train de lire et afficher l'image qui est dans le frontbuffer;
2. Il n'a pas terminé sa synchro verticale alors que la carte graphique présente une nouvelle image dans le backbuffer et le bascule pour que ses données se retrouvent dans le frontbuffer;
3. L'écran continue de lire là où il était, il ne se soucie pas du tout de si c'est la même image ou non, et d'ailleurs c'est pas la même image.

Résultat: on aura un morceau de la première image en haut, et de la seconde en bas. Dans des cas plus sévères de tearing on pourrait avoir plusieurs morceaux d'images différents à l'ecran sur le temps d'un rafraichissement vertical.

Ouais ben je fais ce que je peux hein. Peut-être que vous comprendrez mieux avec une image volée sur Wikipedia:

Le phénomène va de très dérangeant à pratiquement invisible selon les individus quand observé sur un vrai écran montrant une scène en mouvement (parce que si c'est un vieux jpeg immobile il n'y aura pas de tearing hein), et on le perçoit d'autant plus que la V de l'écran est faible.

J'ai filmé quelques situations avec du tearing avec une camera 60 FPS, si vous arrêtez sur image vous devriez clairement l'apercevoir.

En mouvement et sur les extraits où l'écran est en V=144hz, ce sera peut-être moins évident. Pourtant le tearing est toujours là.

Extrait avec l'écran en 60 Hz — J'ai choisi Oblivion parce que le tearing est souvent pire dans des vieux jeux et aussi parce que ça m'amuse:

Et la "même" avec l'écran en 144 Hz:

Un exemple de ce que dont-je parle présentement:

Pour afficher les données de rendu en haut à gauche j'utilise CapframeX juste pour sa fonction Overlay qui elle même utilise le Riva Tuner Statistics server (RTSS) à installer séparément. RTSS est programmé par la même personne que celle qui créé MSI Afterburner et que MSI aurait du mal à payer parce que c'est un Russe et que la Russie a envahi un autre pays en 2022. Vous inquiétez pas si le lien de téléchargement de RTSS est bizarre.

Si vous avez peur des Russes, à juste titre, beaucoup de jeux ont une option d'affichage de statistiques d'images par seconde. Exemple ici pour Warframe:

Une situation idéale implique que ce nombre reste stable, résultant en un temps bien égal séparant la livraison de chaque image.

Ce temps se désigne "frametime" en anglais et la sensation de fluidité d'un jeu peut s'observer en regardant un graphique des frametimes dans le temps. Le frametime (en millisecondes) est aussi visible sur l'indicateur de Warframe.

Un gros pic soudain peut se traduire en une saccade désagréable dans le jeu.

Vous pouvez activer un graphique de frametime avec RTSS. Par exemple via CapframeX:

Un graphique de frametimes tout plat indique une situation idéale où tous les composantes de l'ordinateur et le jeu sont contents, comme ici par ex.:

Si vous avez plus ou moins de FPS que la V qui est active sur votre écran en ce moment, il y aura du tearing.

La V en cours est d'ailleurs à vérifier dans chaque jeu, certains ont une facheuse tendance à sélectionner une fréquence inférieure au maximum de votre écran par défaut.

J'avais mis dans l'intro une situation particulièrement intense de mouvement où on voit tout un tas d'images en même temps et qui provient d'Overwatch 2 avec une limite de 600 FPS:

Bon ma camera ne capture que 60 FPS et mon écran est pas vraiment haut de gamme donc c'est un peu flou. Ceci dit, Certains gens jouent au jeu comme ça. Bon peut-être pas avec vraiment 600 FPS mais au moins 300 et sans technique de réduction de tearing. Je reparle de ces gens 80 pages plus loin dans la conclusion.

La solution originelle: vsync

Le principe du vsync est très ancien et somme toute assez simple.

Du temps des CRT, il était basé sur un signal spécifique surveillé par le contrôleur d'affichage: VBLANK — Le temps mort entre deux images résultant du mouvement de retour du rayon d'électrons, qui doit remonter tout en haut à gauche de l'écran.

Pour ne pas avoir de tearing, il s'agit simplement de basculer backbuffer et frontbuffer uniquement pendant ce VBLANK, et jamais en dehors.

Le basculement d'une nouvelle image devient alors totalement synchronisé avec V, d'où le nom du truc. Yep.

De nos jours avec tous nos écrans numériques il n'y a plus de "rayon d'électron" mais un truc qui a l'air beaucoup moins impressionnant à base de transistors.

Heureusement, peu importe la technologie d'écran, il est toujours possible de synchroniser les basculements de framebuffer avec la synchronisation verticale en utilisant un timing étroitement contrôlé.

C'est pas très clair si ce signal VBLANK existe toujours au niveau des contrôleurs d'affichage mais ce dernier est tout le temps au courant d'où il en est précisément dans sa lecture du frontbuffer et de quand le balayage vertical complet de l'écran sera terminé. Donc on en a même pas besoin.

J'en profite pour aussi noter d'emblée que vsync est activé par défaut dans beaucoup de jeux.

Il peut aussi être forcé (globalement ou par jeu) dans le panneau de contrôle de vos pilotes graphiques. Une division existe déjà à ce niveau entre les gens qui préfèrent l'activer dans les pilotes et pas dans le jeu, et... Ben les autres qui font l'inverse.

Le vsync des pilotes est le plus "pur", parfois celui des jeux produit exactement le même résultat. Dans d'autres cas, les développeurs activent d'autres "optimisations" en même temps que vsync, ce qui peut-être bien, ou moins bien.

Par exemple, dans Warframe en mode Captura (j'ai pas essayé en dehors du Captura) sans limite de FPS et sans vsync, j'ai quand même pas de tearing. C'est qui est totalement anormal et me fait dire que, eux, ils activent des "optimisations" même si t'as pas vsync activé (qui ressemble à du triple buffering, expliqué en détail plus loin). C'est un peu la jungle avec parfois des différences selon les jeux.

Personnellement je n'utilise souvent pas vsync du tout donc je peux pas trop vous conseiller sur le sujet et je pense que vous pourrez vous conseiller tout seul après avoir survécu à cet article.

Problème numéro 1: j'ai pas assez de FPS

Vsync élimine donc complètement le tearing, que vous ayez trop ou trop peu de FPS.

Si vous avez plus de FPS que la V de l'écran, vos FPS effectis se retrouvent verouillées exactement à la V de l'écran. Par exemple, avec un écran 60 Hz, on se retrouve avec pile 60 FPS.

Si on a moins de FPS que V, parce qu'il y a quelque chose qui est dépassé (un bottleneck comme on dit), vous risquez d'avoir de nouveaux soucis plus ou moins dérangeants que le tearing lui-même.

Va me falloir un autre petit scénario:

1. Vsync est activé;
2. Le frontbuffer a été entièrement lu et affiché par l'écran mais le GPU n'a pas terminé de dessiner le backbuffer;
3. On a atteint le moment où on aurait dû basculer les framebuffers, mais on peut pas;
4. Une micro-seconde plus tard, le GPU a terminé de générer l'image;
5. Sauf que maintenant il faut attendre la fin d'un nouveau rafraichissement vertical pour basculer les framebuffers, et l'écran est en train de lire les mêmes données qu'il avait déjà affiché dans le frontbuffer qui n'a toujours pas été basculé.

En gros, si une image n'est pas prête à temps dans le backbuffer il faut attendre au minimum la prochaine synchro verticale pour pouvoir basculer les framebuffers.

Ce phénomène a tendance à accentuer les pertes de FPS occasionnelles qui peuvent être courantes dans certains jeux ou avec du matériel un peu fatigué puisqu'on peut se retrouver bloqué avec un taux de FPS d'une fraction de V, parfois jusqu'à la moitié, alors que la carte graphique en sort ~48.

J'ai jamais rien compris au calcul donc on va juste dire que c'est pas cool.

En plus, un écran qui affiche la même image sur plusieurs cycles de rafraichissement ça donne une impression de saccades ou hachage qu'on appelle aussi communément un vieux lag.

J'ai essayé de le filmer (camera 60 FPS) en limitant artificiellement Oblivion (super choix de jeu je sais) à 33 FPS sans vsync puis avec vsync.

Bon de base ça a pas l'air ultra choquant parcque mon 33 FPS est ultra stable (pas avoir 33 FPS ultra stables dans Oblivion en 2023 c'est un peu le tristodésespoir), ce qui aide à rentre le truc plus tolérable.

D'abord sans vsync, où vous pourrez trouver du tearing en arrêtant sur image:

Puis avec:

Vous pouvez arrêter sur image la vidéo avec vsync où vous voulez, il n'y aura pas de tearing.

Problème numéro 2: input lag

Si la carte graphique produit trop de FPS par rapport à V et que vsync est actif, il y a des moments où la carte graphique doit juste attendre parce qu'elle a déjà fini son petit dessin dans le backbuffer.

Le truc c'est que les petits dessins de la carte graphique ont été demandés par la boucle de jeu ou le rendering thread qui, pour bien faire, doit aussi attendre avant de pouvoir montrer le résultat des actions du joueur à l'écran.

Et ça mes amis, c'est la définition de l'input lag qu'on est bien contents d'avoir défini plus haut parce que là on comprends trop bien, quoi, ce week end j'explique tout ça à mémé.

Cela signifie également économie d'énergie (et donc moins de chaleur produite) puisque le processeur et la carte graphique ne font (presque) rien quand ils attendent.

Quand les FPS<V, il y a aussi de l'input lag dû à devoir attendre la prochaine synchro verticale pour pouvoir basculer les framebuffers quand une nouvelle image est prête. Les cas où l'image était justement prête tout au début d'un nouveau cycle de rafraichissement vont produire le plus d'input lag.

Tout ça reste relatif parce qu'au plus un cycle de rafraichissement est rapide (c'est-à-dire au plus V est élevé), au moins il faut attendre et donc au moins l'input lag est affecté. Ceci dit, la plupart des "vieux" écrans sont en 60 Hz, où l'effet est considéré significatif par beaucoup d'humains.

En résumé: vsync seul resulte (presque) toujours en une augmentation de l'input lag.

J'en vois un derrière qui se demande pourquoi y a un "presque" entre parenthèses alors que les autres font semblant de pas l'avoir vu.

En fait si vos FPS sont un micro-poil sous la valeur de V, et y restent pour toujours, l'input lag disparait presque totalement parce qu'il ne faut jamais attendre.

Avant que toutes les technologies que je vais évoquer dans cet article soient d'actualité, des petits malins avaient découvert une technique de hacker à base de programme Russe (c'est le même dont on parlait plus haut mais ça fait plus UNDERGROUND comme ça) pour avoir vsync seul et limiter au maximum l'input lag, à un point qu'il disparait presque complètement.

Je ne mets pas cette "astuce" dans sa propre section parce qu'elle n'a (selon moi) de sens que si vous avez:

• Une carte graphique "ancienne" (GTX 9xx / AMD RX 3xx);
• Un écran ou TV qui ne supporte ni gsync ni freesync;
• Un cas de jeu où votre ordinateur est clairement capable de produire plus de FPS que la V de l'écran en question;
• Un sens aigu de la bidouille.

Il faut aussi être réellement gené par l'input lag qui en réalité est peu dérangeant sur un bon nombre de jeux. Il y a des gens qui jouent à des jeux "dans le cloud" sur un ordi qui se trouve dans un autre pays avec un input lag de cochon dinde et ils ont l'air contents donc... Voilà quoi. Si ça vous convient, changez rien.

Je trouve que ça fait beaucoup de conditions à remplir avant d'avoir un vague intérêt pour cette technique. Je vous invite à consulter cet article (en anglais) si ça vous intéresse.

Il s'agit d'utiliser RTSS pour limiter les FPS à une valeur très proche de V, au niveau décimal — Seul RTSS permet de limiter les FPS à la décimale près que je sache.

Vous devez ensuite tester si ça améliore réellement l'input lag, sinon il faut incrémentalement baisser le limiteur de FPS jusqu'à ce que ça soit correct.

C'est du chipotage, ça doit se faire individuellement pour chaque jeu et il faut RTSS qui tourne, de nos jours on a quelques alternatives moins compliquées.

Les trucs annexes et connexes à vsync

Les gens se sont beaucoup allongé les poils de nez en cherchant un moyen d'éliminer le tearing sans activer vsync.

Le problème c'est qu'il y a tearing dès qu'un buffer est passé comme frontbuffer alors que l'écran était justement en train de lire le dit frontbuffer et cet enfoiré est TOUT LE TEMPS EN TRAIN DE LE LIRE. Le seul moment où c'est pas le cas, c'est pile poil quand il vient de finir un scan vertical complet ou quand il est sur le point de commencer un nouveau scan (ce qui correspond au même moment en pratique).

C'est le seul moment où on peut basculer d'image... Ce qui nous amène au premier constat triste de la soirée: c'est pratiquement impossible d'éliminer entièrement le tearing sans vsync. En tous à l'heure d'aujourd'hui de 2023 sur la terre.

Par contre on peut imaginer deux ou trois compromis, un peu comme quand les gens fabriquaient des préservatifs en boyau de porc; c'est pas parfait mais c'est mieux que rien. Je crois.

Adaptive sync

On va passer vite sur adaptive sync parce que ça porte à confusion avec les technologies gsync/freesync décrites plus loin et ça ne fonctionne que sur les cartes Nvidia.

C'est une option qui s'active au niveau des pilotes ce qui implique générallement d'ouvrir ce bon vieux panneau de contrôle Nvidia, une interface développant une forte odeur de vieux grenier mais qu'on est bien content de retrouver la même depuis 15 ans quand on est un vieux con comme moi.

Pas de transparence et jeu de couleur rouge et police de caractère de combat, juste, le vieux panneau de contrôle Nvidia. Il est même pas ergonomique, il est même pas beaux. Ils s'EN FOUTENT c'est génial.

Vous pouvez normalement l'ouvrir en cliquant droit sur son icône dans la barre de notification. Il s'agit ensuite de se rendre dans "3D Settings", et choisir l'onglet "paramètres globaux" ou "spécifiques à un programme".

Je ne vous conseille pas d'utiliser les paramètres globaux avant d'être vraiment sûrs de vous, surtout si c'est pour activer adaptive sync.

Aussi, si vous ne voyez pas l'option, c'est parce que vous avez gsync activé.

En effet l'option ne sert absolument à rien avec gsync/freesync parce que son fonctionnement implique de ne rien faire dans la plage de fréquence ou gsync/freesync est actif.

Quelqu'un chez Nvidia s'est dit un jour que ce serait cool d'avoir un genre de vsync qui ne s'active que si les FPS>V.

En dessous de ça, vsync est automatiquement désactivé. Mais... Alors, dites-vous, ça veut dire qu'on a du tearing si FPS<V, non?

Oui.

Voilà.

L'option a tout de même du sens parce que beaucoup de gens trouvent que le tearing FPS<V est moins embêtant que celui quand FPS>V et surtout que le lag/stuttering (images qui se répêtent de manière irrégulière) et le vécu face au jeu est juste pire avec vsync activé.

De plus, désactiver vsync dans le cas FPS<V avec une machine qui peine à faire tourner le jeu va réduire la casse en terme de pertes de FPS potentielles.

En résumé:

• Marche que sur les cartes Nvidia parce qu'AMD a décidé un jour de balancer cette option dans la poubelle de l'oubli déjà bien remplie chez ce constructeur;
• Doit être activé dans le panneau de contrôle Nvidia, idéalement au cas par cas;
• Totalement inutile si votre ordi + jeu arrive toujours à produire plus de FPS que V parce que c'est la même chose que vsync dans ce cas là;
• Si FPS<V il y aura du tearing.

Le triple buffering et les autres bufferings aussi, allez hop

Je choisis de parler de triple buffering pour essayer de lever la confusion qui plane sur cette technologie et qui est aussi un peu la faute du terme en lui-même.

Le terme "triple buffering" ça pourrait juste vouloir dire qu'il y a trois framebuffers au lieu des deux (back et front) évoqués jusqu'ici. Et c'est bien ça que ça veut dire sauf qu'historiquement on lui colle deux ou trois implications en plus.

Accrochez-vous à votre slip.

En pratique personne ne sait réellement ce que veut dire triple buffering, ça dépend du jeu, de l'époque et de l'alignement des planètes.

Au départ, c'était censé ajouter un backbuffer en plus et permettre à la carte graphique de ne jamais devoir attendre.

Une fois qu'elle a rempli un backbuffer, il est immédiatement permuté avec l'autre backbuffer et le GPU commence immédiatement à dessiner une nouvelle image dans l'autre backbuffer.

Pendant ce temps, le GPU bascule le backbuffer le plus récent en frontbuffer lorsque qu'un balayage complet de l'écran vient d'être effectué — C'est à dire comme avec vsync. Le vrai, pur et aryen triple buffering implique vsync en plus, toujours (il faut pas l'activer c'est implicite).

Le backbuffer supplémentaire permet au GPU de ne jamais devoir attendre s'il produit plus de FPS que V. Parce que sinon avec vsync simple, il aurait dû attendre (et probablement le game loop / render thread aurait dû attendre aussi), ce qui augmente l'input lag.

Avec le triple buffering, le GPU peut cracher autant de FPS qu'il veut sans soucis et il n'y a pas de tearing (puisque vsync est actif, je rappelle).

Le seul inconvénient c'est qu'il y a des images qui sont jetées à la poubelle si l'écran est vraiment lent puisque c'est le backbuffer le plus récent qui passe en front après synchro verticale, peut-être que le GPU avait dessiné une dizaine d'images sur ce temps.

Ce phénomène génère de petites saccades peu ou très perceptibles selon les individus.

Aussi, on a jamais rien sans rien, le triple buffering permet au GPU balancer un max d'images, c'est à dire qu'il va augmenter sa charge (jusqu'à 100% si le CPU peut suivre) et sa consommation.

J'espère que vous avez bien kiffé toutes ces explications parce qu'elles ne décrivent pas le triple buffering le plus souvent évoqué dans les jeux modernes. Le "triple buffering" implémenté comme je viens d'expliquer a pour ainsi dire disparu (SPOILER: IL VA REVENIR PLUS TARD LOL je suis tout excité).

D'ailleurs, dans le panneau de contrôle Nvidia et l'équivalent AMD, l'option est marquée comme "pour OpenGL uniquement" — Vous connaissez beaucoup de jeux OpenGL (c'est une API graphique) qui n'ont pas 150 ans, vous? Moi pas.

La même chez AMD où OpenGL est même dans le nom de l'option, merci AMD:

Bon mais alors, pourquoi ça marche pas avec DirectX (et Vulkan)?

Jusqu'à présent j'avais simplifié les framebuffers avec un back et un front, en laissant trainer la rumeur que parfois il y en a plus, et on vient d'ailleurs de voir que l'idée du triple buffering c'est d'ajouter un backbuffer.

En réalité, les API graphiques modernes utilisent une liste de backbuffers appelée swap chain ou render queue.

C'est une FIFO (file de données) dont on a pas le temps de discuter l'implémentation (bien dommage n'est-ce pas) contenant le frontbuffer courant en tant que dernier élément de la file, et un certain nombre de backbuffers qui le précèdent.

C'est à dire que quand on a terminé d'écrire dans le premier backbuffer, toute la file avance et le dernier backbuffer devient frontbuffer (si vsync l'autorise dans le cas où vsync serait activé).

Pourquoi travailler comme ça? Je pense qu'il y a deux raisons.

La première, c'est un lissage de taux de FPS. Effectivement, si certaines images mettent beaucoup plus de temps à être calculées (ce qui peut vouloir dire que l'ordi a du mal, que le moteur de jeu est tout pourri ou les deux), c'est pas grave parce qu'il y a plusieurs images déjà prêtes dans la file qui jouent le rôle de tampon.

Ceci améliore ce que d'autres appellent en anglais le frametime consistency, où frametime étant le temps qu'il faut pour produire une nouvelle image.

Avoir un taux de FPS qui varie tout le temps est très désagréable, au point que beaucoup de gens préfèrent un 30 FPS stable avec un peu d'input lag additionnel qu'un 50 FPS en moyenne mais qui oscille sans arrêt entre 5 et 80 FPS.

La seconde raison, selon moi, vient du temps où on combinait plusieurs cartes graphiques pour créer une abomination probablement responsable de la noyade de moulte ours polaires, où chaque carte graphique calcule alternativement une image.

Avec une file de backbuffers, chaque GPU peut enfiler (oui ça se dit vraiment comme ça) son image dans la structure de données et tout est naturellement poussé vers le frontbuffer, il suffit d'avoir au moins autant de backbuffers que de cartes graphiques.

Je pense que le multi-GPU a plus ou moins disparu de nos jours. Il n'empêche qu'il est toujours supporté.

J'imagine que la file d'attente de backbuffers est aussi plus simple à harmoniser avec une file d'attente de scènes à calculer par exemple. Il y a certainement d'autres avantages.

Exceptions en mode fenêtré

Je déconseille d'utiliser les mode fenêtrés, que ça soit "mode sans bordure" ou juste fenêtré tout court.

Certaines implémentations utilisent le même système de buffering que Windows utilise pour ses petits dessins dans des fenêtres, et c'est un genre de triple buffering tel que je viens de l'expliquer additionné à vsync.

Effectivement, le triple buffering standard a surtout disparu dans les jeux, les moteurs d'interface graphique (comme Gnome sous Linux par exemple) implémentent souvent du triple buffering pour rendre leurs animations plus fluides sur le matériel le plus modeste.

Tout cela nous amène à un l'input lag est historiquement plus élevé en mode fenêtré.

C'est possible que ça ait changé avec Windows 11 (ou Windows 10 avec toutes les mises-à-jour) et certains jeux, mais je compterais pas dessus tout de même.

Conclusion: N'utilisez pas le mode fenêtré (avec ou sans bordure) si possible.

Le faux triple buffering

Je l'appelle faux triple buffering alors que c'est le seul qui existe en pratique dans le monde moderne. Enfin, non, c'est le seul qui est appelé comme ça. Peut-être que c'est le vrai triple buffering du coup. Qui suis-je pour en juger?

Dans les applications qui utilisent les API graphiques Direct3D ou Vulkan il y a parfois un élément tranquillement nommé "triple buffering" dans le menu des options.

Ce qu'ils entendent secrètement par triple buffering, c'est qu'il vont créer une swap chain faite de deux backbuffers et un frontbuffer (il n'y a jamais qu'un seul frontbuffer je sais pas pourquoi je le précise).

Ce qui ressemble assez bien à l'explication initiale du triple buffering qui utilise deux backbuffers. Sauf qu'en fait c'est pas pareil.

La swap chain est une file d'attente, on peut sortir le dernier membre quand on en a besoin mais on ne jette aucune image, elles finissent toujours par atterir dans le frontbuffer.

Vous avez sûrement déjà oublié mais le triple buffering "originel" consiste à écraser le backbuffer le moins récent avec chaque nouvelle image. Rien ne dit que ce backbuffer a été passé en frontbuffer et affiché. Peut-être qu'il l'a pas été parce que l'écran est beaucoup plus lent que la génération d'image, auquel cas on vient de balancer une image au paradis des pixels.

Le triple buffering Direct3D/Vulkan ne balance aucune image. Et c'est bien dommage parce que ce balançage d'image c'est ça qui éliminait l'input lag.

Ben ouais, le "faux" triple buffering, il ajoute de l'input lag. Mince alors.

La règle pour le "faux" (ou vrai ou tout ce que vous voulez) triple buffering, c'est qu'il faut toujours le désactiver sauf si votre ordi n'arrive que rarement à produire suffisamment de FPS pour approcher de V et est clairement un peu en galère — Dans ce cas là ajouter des éléments dans la swap chain rendra l'expérience plus fluide, au prix d'une augmentation de l'input lag.

Ce triple buffering ne nous débarasse pas non plus du tearing, pour ça il faut activer vsync en plus alors qu'il était implicite pour... L'autre... Triple buffering.

Avec plus de FPS que V, l'input lag induit par vsync s'ajoute à la réalité qu'il y a maintenant aussi une image de retard. C'est potentiellement encore pire que vsync seul, alors que le "vrai" triple buffering, celui qui est autorisé à balancer des images à la poubelle, n'aurait eu que peu d'effet sur l'input lag.

Par contre, avoir une swap chain d'au moins 3 éléments, vsync actif et des FPS < V permet d'atténuer le phénomène de grosse perte de FPS si les FPS fluctuent pas mal sous la valeur de V, et ça c'est vrai pour les deux "types" de triple buffering.

Au moins trois éléments? C'est là que le voile s'effondre. On parle de "triple buffering" depuis tout à l'heure mais les programmeurs du jeu peuvent choisir la taille de la swap chain et la changer selon leurs propres métriques s'ils le désirent (sauf si l'option est forcée par les drivers).

Rien n'empêche certains développeurs de vous bourrer secrètement une swap chain de 4 éléments, sans aucune option dans les menus. Vous êtes alors en QUADRUPLE BUFFERING sans le savoir et eux peuvent se permettre d'avoir un moteur de jeu tout moisi qui prend secrètement 5 fois plus longtemps à calculer certaines images par rapport à d'autres mais vous n'y voyez que du feu — MAAAGIIIIEeeeeeeeeeeeeeeee.

En résumé, ajouter des backbuffers va aider à lisser les variations de taux de FPS au prix d'une augmentation de l'input lag.

Forcer le double buffering

Enfoncés aussi profond dans l'article, notre innocence est déjà brisée par la révélation de l'existence des swap chains d'un nombre plus ou moins arbitraire de backbuffers.

Si vous êtes un gros privilégié du matos ou si vous jouez juste à Valorant en 1024x768, votre ordinateur produit à tout moment bien plus de FPS que la V de l'écran et vous n'avez pas non plus besoin d'améliorer la constance de ces FPS, elle est déjà parfaite (sauf si y a un Windows Update surprise et que McAfee doit mettre à jour ses LEDs RGB en même temps).

Dans ce cas, avoir plus de backbuffers que un seul est juste un frein à votre glorieuse opulence dont vous êtes, grand bien vous fasse, extrêmement fier.

La chance, c'est possible de forcer la taille de la swap chain au minimum dans les options du pilote. Le pas-de-chance, c'est que cette option change de nom tout le temps, rien n'est clair, ça marche pas du tout dans les jeux DirectX 12 (me demandez pas pourquoi j'en sais rien), et de toutes façons les jeux compétitifs utilisent déjà le minimum de buffering par défaut et en plus la valeur par défaut dans les pilotes est déjà le minimum.

Sauf par exemple Overwatch, qui a une option "Reduce buffering" qui force le double buffering. Mais alors, on avait combien de buffers avant? A combien de buffers correspond réellement l'option tripole (je laisse cette faute de frappe) buffering qui est pas loin dans le même menu? Il se passe quoi si on active les deux en même temps? What ZE OTARIE???

[J'ai aucune explication, je vous laisse salut]

Les limiteurs de FPS

A la base et si vsync ou équivalent est désactivé, le GPU sort autant d'images qu'il peut par seconde; tant que le game loop ou render thread lui fournit des scènes à calculer.

C'est à dire tant que le CPU n'est pas complètement surchargé parce qu'il est trop faible et/ou parce que le jeu est très mal programmé.

Pour certaines combinaisons de matériel et de jeu, ça fait juste BEAUCOUP TROP DE FPS le tout accompagné d'une consommation élevée d'énergie pour le CPU et le GPU.

Les limiteurs de FPS ont tous la même finalité: essayer de dire au CPU d'arrêter de présenter des milliard de scènes 3D à calculer pour le GPU, lui dire d'attendre quoi.

Un CPU passe déjà la majorité de sa vie à attendre des trucs donc on est pas à ça près.

Les limiteurs de FPS agissent par conséquent avant que l'image ne débarque dans le 3D pipeline physique.

Il en existe deux grands types.

Le limiteur inclus dans le jeu

Le jeu peut s'informer de combien de FPS il génère et se dire WOWOWOW, on se calme un peu là! Et éviter de présenter de nouvelles images quand il y en a déjà trop, il passe simplement à la prochaine itération de la boucle.

C'est au choix des développeurs d'accompagner cette action d'autres économies. Par exemple, ce serait vachement malin de ne pas calculer du tout la scène 3D (au niveau CPU, donc) si de toutes façons on ne va pas l'envoyer au GPU.

Quoi qu'il en soit, tous les limiteurs de FPS ajoutent un petit peu d'input lag, c'est le cas dès que quelque chose doit attendre dans l'ordinateur, que ça soit le CPU ou le GPU.

La qualité de l'intégration du limiteur de FPS et les économies qu'il engendre (ou pas) vont décider de la pénalité d'input lag qu'il occasionne. Cela dépend donc des jeux et de leurs développeurs, ce qui devrait, judicieusement, vous faire légèrement peur.

La précision du limiteur dépend aussi de son implémentation. Les limiteurs intégrés au moteur de jeu sont toujours moins précis que les limiteurs au niveau du pilote (voir section qui suit) — c'est-à-dire que les FPS ont tendance à bouger autour de leur limite, un peu en dessous et un peu au dessus et ça s'empire au plus votre ordinateur est FAIBLE.

Les jeux n'ont pas tous un limiteur intégré ou parfois proposent uniquement quelques options comme 60, 80, 120, etc. (Fortnite est comme ça il me semble).

Je n'exclus pas qu'il puisse exister des raisons valides de ne pas ajouter un limiteur de FPS à un moteur de jeu, c'est évident que ça complexifie la boucle et qu'il y a plus de choses à prendre en compte lorsque de nouveaux éléments s'ajoutent à la boucle.

Les limiteurs au niveau du pilote

Les jeux et programmes 3D envoient des demandes de "présentation" de nouvelles images à l'API graphique, lesquelles passent ensuite par le pilote via un appel système.

L'idée du limiteur "pilote" est de créer un temps d'attente artificiel entre la réponse du pilote et l'API graphique, qui elle même va transmettre ce retard au programme qui crée les scènes 3D.

Enfin, je crois, je ne suis pas certain de tous les détails de l'implémentation.

Vous pourriez aussi le voir comme le pilote faisant semblant que le GPU est moins puissant qu'il l'est si les FPS sont plus élevés que la limite fixée. Le GPU a tout à coup l'air d'être, comme par hasard, juste assez balaise pour produire exactement le nombre de FPS de la limite. COMME PAR HASARD, mon conspirationnisme est en train d'érecter (je pense que c'est pas un vrai verbe).

La limitation au niveau du pilote est très précise et utilise en théorie un peu plus de puissance processeur qu'un limiteur en jeu puisqu'il n'est pas possible de réaliser des économies en se retenant de calculer des scéènes 3D inutiles.

Cette différence est normalement ridicule par rapport à l'économie réalisée en attendant artificiellement. Donc on s'en fout.

Toujours est-il que ce travail en plus, selon la lourdeur de la boucle de jeu, va générer une certaine dose d'input lag qui reste, je trouve, très faible mais néanmoins légèrement plus élevée que celle engendrée par un limiteur intégré au moteur de jeu qui aurait été bien conçu. Oui ça fait une chiée de conditions, je suis désolé. Mon univers est aussi devenu beaucoup plus compliqué depuis cet article.

J'ai déjà évoqué quelques fois RTSS, ce programme permet d'appliquer le même type de limite de FPS et de manière encore plus précise (à la décimale près!) en se branchant quelque part dans l'API graphique ou le pilote, je comprends pas trop comment ça marche à vrai dire mais c'est une technologie connexe à celle qui permet de créer des overlays comme celui de Steam par exemple. Si vous voyez pas de quoi je parle c'est pas grave.

Je conseille pas RTSS parce qu'il faut régulièrement le réinstaller et que ça reste un programme tiers bizarre, même si c'était pas codé par un Russe dans une cave quelque part.

Vous pouvez définir la limite de FPS du pilote dans le panneau de contrôle de la carte graphique.

Par exemple, pour Nvidia, vous pouvez définir une limite globale (par défaut quoi) ou une limite spécifique par programme:

Je préfère ne pas activer de limite globale parce que j'utilise le limiteur en jeu s'il y en a un. Par contre j'utilise très souvent la limite "par programme".

Chez AMD le marketing a légèrement pris le dessus et la limite de FPS du pilote passe par une fonctionnalité nommée Radeon CHILL — Littéralement MODE COoooooL et frais.

Chill ajoute une couche sauver-les-baleines au limiteur (qui baisse déjà la consommation de base je rappelle (tant qu'il limite quelque chose)) en permettant d'automatiquement baisser la limite de FPS quand aucun mouvement n'est détecté dans le jeu (le GPU peut se rendre compte facilement qu'il dessine plus ou moins la même chose tout le temps) pour économiser encore plus d'énergie.

J'ai pas de carte AMD mais d'après ce que je lis, ça fonctionne plutôt bien.

A vous d'expérimenter avec la limite "Min FPS". Pour configurer une limite "classique" il suffit de mettre la même valeur pour "Min FPS" et "Max FPS", et voilà.

Le panneau de contrôle du pilote AMD Permet normalement de créer un profil pour un jeu spécifique et lui coller l'option CHILL avec ses propres valeurs de FPS Min/Max.

Quelque soit votre camp et votre choix de limite globale ou par jeu, veillez à ne pas activer plusieurs limiteurs de FPS en même temps. C'est pas nécessairement nocif, mais votre risque d'observer des TRUCS BIZARRES augmente significativement.

Effets des limiteurs de FPS

On a déjà parlé de l'input lag ajouté, c'est important de se rappeler qu'il est très faible — Beaucoup plus faible que l'input lag généré par vsync.

Résumons tout ça:

• Les limiteurs ne limitent rien du tout si vos FPS sont sous la limite 🧐 (ceci dit ils ne font [normalement] pas de mal non plus);
• Une limite de FPS égale à (ou très proche de) V (légèrement en dessous est le mieux) élimine presque tout le tearing sans avoir besoin de vsync — Ce sera à vous de voir si vous en avez encore besoin selon votre impression personnelle et votre combo matériel/écran/jeu;
• A ce sujet: si vous préférez vsync à un limiteur égal à V, désactivez le limiteur et laissez vsync seul (ou fast/enhanced sync si vous préférez);
• Le limiteur ajoute un peu d'input lag mais beaucoup moins que vsync et les limiteurs intégrés aux moteurs de jeu induisent [normalement] moins d'input lag que le limiteur du pilote graphique;
• Si votre GPU produit artificiellement moins de FPS, la consommation de tout l'ordi baisse, ce qui veut aussi dire qu'il chauffe moins et que les ventilos tournent moins vite, ça sert souvent à rien de le faire tourner à 100% et réchauffer tout l'Antarctique;
• Il faut éviter d'activer plusieurs limiteurs de FPS en même temps.

Gsync / Freesync

Quelque part en 2015, Nvidia est toujours en train de ruminer sur des alternatives à vsync.

C'est alors que, coup de génie, est-ce qu'on pourrait-y pas juste dire à l'écran d'ajuster non-stop sa V pour correspondre au taux de FPS qui sort de la carte graphique?

Ce serait quand même bien pratique, je sors 45 FPS, je demande à l'écran de se mettre en 45 Hz. Boom, plus de tearing (note de l'auteur: presque plus de tearing).

Tout le monde chez Nvidia se dit que c'est trop cool et ils inventent un "module" secret, lequel doit être programmé de manière spécifique pour chaque écran qui sera compatible avec leur nouvelle technologie baptisée Gsync.

Initialement il y a deux conditions majeures: l'écran doit embarquer ce "module" avec des règlages qui vont bien pour cet écran et le cable utilisé doit être un DisplayPort version 1.2 minimum, pas de support de cette technologie sur HDMI à l'époque.

Les enthousiastes sautent sur ces écrans Gsync et GSYNC ULTIMATE (aucune idée de la différence) pourtant affublés d'un surcoût non négligeable.

Je pense que personne ne leur avait dit qu'ajuster la V de l'écran à une limite. Un écran qui peut max afficher 80 Hz, si je lui balance 200 FPS il peut pas faire mieux que 80 Hz. Du coup y a masse de tearing et faut activer vsync (LOL).

Bon, je dramatise un peu, il suffit en réalité d'utiliser un limiteur de FPS pour s'assurer de rester en permanence un petit peu en dessous de la Vmax de l'écran, et on est tranquilles.

Vla-t-y pas que, un peu plus tard, l'association de standardisation "vidéo électronique" (VESA) arrive avec un plan pour que les écrans puissent ajuster leur V en réponse au taux de FPS que produit la carte graphique, et il faut pas de "module" secret fabriqué par Nvidia: ils publient toutes les spécifications pour ajouter la technologie aux écrans sans devoir payer cher et méchant.

Le truc est parfois malencontreusement nommé "display adaptive sync" dans la littérature. Le terme est très à propos, c'est juste dommage que c'est exactement le même qu'une alternative à vsync vaguement abandonnée et spécifique à Nvidia que j'ai décrite bien plus haut dans sa section "Adaptive sync". He ben c'est pas le même adaptive sync, au cas où tout ça était un peu trop clair pour vous.

Revenons à nos écrans. Nvidia a un mono-concurrent sérieux, AMD (maintenant y a aussi Intel mais ils comptent pas (encore)), qui est moins populaire pour diverses raisons.

Comme les gens ont tendance à bouder AMD, les bougres essayent de sortir des solutions plus accessibles, basées sur des standard, et même de les partager en source ouverte.

Vous avez le droit de me trouver cynique, je pense que si AMD était à la place de Nvidia, ils ne sortiraient rien d'Open Source et essayeraient aussi qu'on paye bien cher pour leurs technologies bien fermées.

Toujours est-il qu'AMD sort sa version de Gsync qu'il appelle Freesync (PASKE C GRATUIT TA COMPRI?? Nvidia rend l'argent!) et qui est basé sur le standard VESA et nécessite un cable DisplayPort 1.2a qui supporte l'adaptative sync (pas systématique).

Une floppée d'écrans Freesync apparaît puisque c'est plus simple et moins cher à mettre en place que Gsync.

Tout ce capitalisme qui fonctionne normalement n'était pas prévu dans les plans de Nvidia. Ils se résignent tristement à sortir le plan Gsync Compatible signifiant sur le fond que les écrans qui ont "AMD freesync" marqué partout sur le paquet offriront leur V adaptative sur cartes graphiques Nvidia aussi. C'est la honte mais bon.

Comme faut quand même pas abuser, Nvidia limite le Gsync compatible aux cartes Pascal (par ex. GTX 1060) ou supérieure, et il faut aussi un cable DisplayPort 1.2a.

Freesync est souvent "moins bien" que Gsync, mais pas nécessairement. La qualité dépendra du fabriquant de l'écran et de la volonté de Nvidia d'ajouter un genre de profil pour cet écran, qui dépend sans doute de la relation des deux entreprises.

De nos jours je pense qu'un bon écran Freesync sera très confortable que vous ayez une carte graphique AMD ou Nvidia.

Les choses à savoir sur ces technologies:

• Ne sert absolument à rien du tout quand FPS > V;
• Demande un écran compatible;
• Possède une limite basse, souvent autour de 30 Hz, l'écran est incapable d'ajuster en dessous de ça;
• L'option doit être activée au niveau des pilotes et du menu de l'écran;
• N'élimine pas totalement le tearing à FPS < V mais y arrive presque (surtout si les FPS sont bien constants);
• Affecte très peu l'input lag;
• Pas de saccades, peu importe les FPS.

C'est difficile à décrire sans le voir par vous mêmes. Je dirais juste que Gsync/Freesync rendent l'expérience de jeu plus agréable, il n'y a aucune raison des les désactiver à moins de vraiment poursuivre l'extrême limite basse de l'input lag qui à mon avis sera davantage un placebo goût cancoillotte qu'un réel avantage.

Chez Nvidia, Gsync a sa propre section du panneau de contrôle et peut être activé en "plein écran" et/ou "fenêtré". Je ne vois jamais personne qui active le mode fenêtré et je le fais pas non plus, je mets bien toujours tout en plein écran de toutes manières.

Certains jeux secrètement fenetrés comme Guild Wars 2 fonctionnent tout de même avec Gsync donc tout ça n'est pas très clair.

Ils ont ajouté une option bizarre pour vérifier si gsync est activé, même si le mieux c'est d'essayer de voir si votre écran a une option du même acabit.

Ce qui affiche ce tout petit truc magnifique en jeu si gsync est actif:

Gsync / Freesync doivent être accompagnés

Il y a un gros et un petit soucis avec gsync/freesync, j'avais mis en le gros en gras un peu plus haut: ces technologies n'ont aucun effet si vos FPS dépassent la fréquence de rafaichissement verticale maximale de l'écran, auquel cas vous allez avoir tout plein de tearing et une consommation élevée.

Le petit soucis c'est que même si FP<Vmax, la synchronisation entre V et FPS n'est ni parfaite, ni instantanée, ce qui génère un petit peu de tearing, souvent tout en bas de l'écran. Moi je le vois même pas la plupart du temps mais c'est vrai que, selon le jeu, ça donne parfois un meilleur ressenti d'essayer de s'en débarasser.

Ces deux problèmes sont résolus en attendant une synchro verticale complète avant de basculer le frontbuffer et on qu'un seul moyen d'avoir ça: vsync... (Et fast/enhanced sync mais ils utilisent secrètement vsync aussi).

En plus, la chance, vsync avec gsync/freesync + FPS<V c'est un cas particulier qui n'ajoute pas d'input lag. Ben ouais il y a toujours une image qui est prête au moment du rafraichissement vertical puisque FPS et V sont plus ou moins les mêmes et donc le moteur de jeu ne doit pas attendre.

J'avais parlé de cette exception en bas de ma section gsync avec l'astuce primordiale pour éliminer l'input lag de vsync consistant à rester dans une plage de FPS la plus proche possible de V.

Gsync/freesync vous maintiennent automatiquement autour de ce cas particulier en faisant varier V. Une image est [pratiquement] toujours prête à chaque fin de balayage de l'écran.

Par contre, quand les FPS>Vmax, là, vsync ajoute son bon gros tas d'input lag, vous avez le même résultat que si vsync était activé tout seul puisque gsync/freesync ne font rien du tout quand FPS>Vmax et oui c'est la 15ème fois que je le dis mais c'est très important.

Si seulement on avait un moyen de maintenir les FPS un peu en dessous de V histoire de bien rester dans la zone ou gsync/freesync est actif. Dommage que ça n'existe pas.

ATTENDS UNE MINUTE bien sûr ça existe! Ce sont les limiteurs de FPS! J'ai bon??

C'est ça Billy! En ajoutant un limiteur de FPS un peu en dessous de V on évite d'arriver dans le territoire vsync bourré d'input lag et on reste de plus dans le territoire d'exception où vsync n'ajoute quasi aucun input lag. C'est génial.

Le nombre d'images à soustraire de V est un peu une question de préférence empirique. Moi j'aime bien "-4" mais vous n'allez vraissemblablement pas être capables de voir la différence entre, par exemple, 140 et 138 FPS. Encore moins entre 360 et 354 voire même 340.

Souvent j'utilise carrément 120 comme limite avec mon écran 144Hz (comment je suis un OUF), voire 100 ou moins en cas de canicule.

Je vis dans un pays où l'énergie est super chère, je limite toujours les FPS.

Alors est-ce qu'on peut juste désactiver vsync avec tout ça? Oui. C'est souvent recommandé de le laisser pour ne pas avoir le peu de tearing qu'il reste, et ça n'affecte presque pas l'input lag comme j'expliquais plus haut, mais parfois je préfère juste gsync + limiteur sans vsync. A vous de voir.

Fast sync / Enhanced sync

Je pense que c'est l'alternative à vsync basique (entendre, qui n'a pas besoin de matériel spécifique, fonctionne sur tous les écrans) préférée par les fabriquants.

Elle doit s'activer au niveau des pilotes et s'appelle Fast sync chez Nvidia et Enhanced sync chez AMD.

Nvidia a décidé de limiter cette option aux cartes Pascal au minimum (ex. GTX 1060) parce qu'être en concurrence avec soi même c'est pénible. Problème de premier monde. En soi il n'y a aucune raison que cette "technologie" ne fonctionne pas sur d'anciennes cartes graphiques (si ce n'est un peu plus de boulot sur le pilote) et je vais vous expliquer pourquoi.

Vous vous souvenez du triple buffering, le vrai et le faux? Vous essayez d'oublier cette partie de votre vie? Je comprends.

J'avais appelé "faux" triple buffering l'idée d'avoir plusieurs backbuffers dans une swap chain Direct3D ou Vulkan (voire même OpenGL "moderne").

C'est cool pour avoir des FPS plus stables, mais ça ajoute de l'input lag parce qu'absolument toutes les images qui entrent dans la swap chain sont conservées là où le "vrai" (je suis tellement désolé) triple buffering peut écraser des images qui ne sont même pas passées à l'écran si le GPU crache trop d'images par seconde.

He ben, vous allez jamais deviner ce que c'est fast/enhanced sync.

C'est le "vrai" triple buffering. C'est tout. Probablement implémenté dans un genre de swap chain mais peu importe, c'est exactement le "vrai" triple buffering que je décrivais plus haut: le GPU est théoriquement toujours en train d'écrire dans l'un des deux backbuffers, et si l'écran est à la traine, on écrase des images qui n'ont pas été affichées, ce qui limite l'input lag.

Le backbuffer le plus récent n'est passé en frontbuffer que quand un balayage complet de ce dernier a été effectué. Oui, comme avec vsync. En fait c'est le véritable vsync + triple buffering. C'est juste qu'ils peuvent pas trop en parler puisqu'on essaye de proposer des alternatives à vsync.

Le principe étant que si votre GPU peut produire au moins autant de FPS que V il y aura toujours une image de prête pour basculement en frontbuffer à chaque nouveau balayage d'écran, et cette image est la plus récente possible. Du coup peu d'input lag et pas de tearing.

Cool!

Par contre ils se gardent bien de parler de la situation où FPS<V, parce que là c'est plus ou moins la même chose qu'avoir juste vsync activé, en un peu moins saccadé puisque le buffer supplémentaire lisse le frametime et avec moins de risque de tomber à la moitié des FPS réelles mais un buffer en plus d'input lag.

Voilà donc toute la vérité: fast/enhanced sync c'est secrètement le "vrai" triple buffering. Comme des images sont jetées à la poubelle si y en a trop (FPS>V), l'input lag augmente beaucoup moins qu'avec vsync dans ce même cas.

En outre, ces images oubliées créent des mini-sauts temporels appelés judder par les pros (comme moi quoi). Du coup c'est pas super génial non plus en fait.

Finalement, le "vrai" triple buffering est un bon candidat de remplacement de vsync si:

• Vous n'avez pas d'écran gsync/freesync (voir section plus loin) parce que sinon il y a bien mieux que fast/enhanced sync;
• Votre ordi est suffisamment balaise pour sortir des FPS>V, de préférence avec une bonne grosse marge de sécurité.

Fût un temps où activer gsync/freesync + fast/enhanced sync était une solution de facilité pour ne pas avoir de tearing en mode global, sur tous les jeux. C'est plus ou moins expliqué par cette vidéo un peu datée qui résume aussi les 3/4 de tout mon article (lol).

Ce cas d'utilisation n'est plus du tout valide et a été remplacé par gsync/freesync + vsync + système anti-lag/faible latence/Reflex.

De fait, comme fast/enhanced sync impliquent aussi un genre de vsync, le GPU envoie à peu près le même nombre de FPS que V à l'écran quand FPS>V, or gsync/freesync ne fonctionnent pas quand FPS>V et sont donc inutiles 99% du temps.

Comme si c'était pas déjà assez nul comme ça, fast/enhanced sync présentent encore un autre inconvénient dont j'avais parlé lors des explications initiales sur le triple buffering: la carte graphique ne doit jamais attendre (c'est le but) ce qui veut dire aussi qu'elle fonctionne à 100%, si elle est suffisamment puissante et que le CPU arrive à suivre.

Dans ce cas, vous êtes à FPS>V et votre carte graphique consomme son maximum de puissance pour pratiquement aucun gain (un tout petit gain en input lag si vous avez au moins 3x V en FPS).

Certains Youtubers ont démontré qu'un GPU a 100% a tendance à augmenter significativement l'input lag en plus de tuer les baleines et de chauffer la pièce comme un grill de kebab.

D'autres ont démontré que ça ne s'appliquait pas à tous les jeux, en particulier les jeux modernes DirectX 12 semblent être plus à l'aise avec le GPU à 100%.

Tout de même, tout ça pour avoir une expérience de jeu légèrement saccadée...

Exemple de mesure de consommation au début du jeu Shadow of the Tomb Raider (désolé il fait tout noir au début dans ce jeu lol):

J'ai découvert dans ce jeu que fast sync ne s'activait pas si vsync était activé dans le jeu. J'ignore à quel point ces "priorités" sont homogènes entre différents jeux.

Liens vers les images complètes:

• Fast sync 1
• Fast sync 2
• Limiteur + vsync 1
• Limiteur + vsync 2

Bien entendu rien n'empêche d'utiliser un limiteur de FPS avec fast/enhanced sync, il faut juste retenir que ce système est prévu pour travailler avec beaucoup plus de FPS que V ou les gains en input lag par rapport à vsync sont négligeables.

Je sais plus pourquoi j'ai une vieille vidéo de Fallout 4 avec fast sync + gsync activés, sans doute pour montrer qu'il n'y a pas tearing malgré les FPS>V (144 Hz dans mon cas) et ce que le judder implique? BON JE LA METS ICI SALUT

Radeon Anti-lag / Nvidia ultra low latency

Nous avons déjà vu plus haut que le nombre d'images pré-rendues — c'est-à-dire aussi la taille de la swap chain de l'API 3D — peut vaguement être configurée dans certains jeux et au niveau des pilotes.

Chez les deux (trois?) fabriquants de cartes graphiques, la taille par défaut de la file est le minimum syndical possible.

La guerre marketing de "l'anti-lag" et la "SUPER fAAAAIBLE LATENC3" est apparue en conjugaison à l'intérêt des gens pour un chouette Youtuber désormais à la retraite: Battle(non)sense, l'arrivage sur le marché de matériel dédié à la mesure de l'input lag ainsi que l'apparition de l'option "anti-lag" chez AMD alors que ça portait un nom de merde chez Nvidia du genre "nombre d'images pré-rendues" et donc ça n'allait pas du tout.

Nvidia change d'abord l'option d'images pré-rendues en... "Images de réalité virtuelle prérendues". Oui personne n'a vraiment tout compris de pourquoi de comment. C'est vrai qu'avoir un max de FPS bien stables est d'importance primordiale pour la réalité virtuelle.

Sauf que l'option fait vaguement croire que ça ne s'appliquera que pour les jeux réalité virtuelle et c'est pas vrai du tout, ça s'applique à tous les jeux sauf ceux qui utilisent DirectX 12 je pense - Oui cette section est très difficile à suivre pour moi aussi.

Le truc mis en avant par Nvidia sera une nouvelle option appelée "Low latency mode" avec les modes Off, On et ULTRA. Ouuuuuh

Le but étant de fonctionnellement copier exactement l'anti-lag d'AMD.

D'ailleurs, parlons-en d'anti-lag, je me suis fait dessus en lisant ça:

Radeon Anti-Lag fonctionne avec tous les GPU AMD "récents" (ceux qu'AMD n'a pas encore abandonné en terme de support pilote) mais uniquement pour les jeux DirectX 11, à moins d'avoir un GPU "Navi" (par ex. Radeon 5700XT) ou plus récent auquel cas les jeux DirectX 9 sont aussi supportés — Marche pô sur DirectX 12 (ni Vulkan ou OpenGL)

Là encore je viens de le relire 3 fois j'ai du mal à tracer toutes les intersections dans ma tête.

Pour être généreux, beaucoup de jeux utilisent DirectX 11 donc c'est pas si dingue que ça.

De plus, le "Low latency mode" de Nvidia ne fonctionne pas non plus avec Vulkan et OpenGL, ni d'ailleurs avec DirectX 12 ou 10. C'est aussi juste 9 et 11. Oui, c'est exactement le même truc copié collé, je l'avais dit.

D'ailleurs à propos de DirectX 12: beaucoup recommendent de ne jamais activer "low latency"/'Anti-Lag" ou de tripoter le nombre max d'images préparées — il y a des témoignages de pertes de FPS et saccades dans ces situations. Je ne l'ai pas vérifié, je relaie juste.

Pour les jeux supportés, ces options baissent la taille de la swap chain au minimum. J'ai comme une impression de déjà vu... Parce que cette option existait déjà et on en a déjà parlé dans une section beaucoup plus haut. Overwatch 2 a même son propre "Reduce buffering".

D'ailleurs, les options d'anti-lag n'ont aucun effet si "Reduce buffering" est activé dans Overwatch — Probablement parce que c'est la même chose.

Que je sache, il n'y a aucune différence entre le mode "low latency" On et Ultra chez Nvidia et personne n'a l'air d'avoir d'info fiable là dessus sur tout l'internet (à part quelques mesures où ça change vraiment RIEN).

Peut-être qu'il y a secrètement un effet sur l'utilisation énergétique du GPU mais comme tout le monde s'en fout, ça n'est jamais mesuré, et moi j'ai pas le temps.

En résumé, au plus le temps passe au moins cette option restera utile puisqu'elle n'a aucun effet sur les jeux DirectX 12 et les jeux qui font déjà le maximum pour réduire la taille du tamponnage.

J'entrevois bien un cas d'utilisation un peu cocasse qui est gsync/freesync + vsync + anti-lag/low-latency.

Cette magnifique équation ressemble (SPOIL) à la config optimale avec gsync/freesync dont je parle en conclusion, c'est juste que l'anti-lag remplace le limiteur de FPS.

Et... C'est ça le cas d'utilisation. L'anti-lag/"mode basse latence" combiné à vsync empêche naturellement que les FPS approchent de V, ce qui permet de rester tranquillement dans la zone gsync/freesync sans devoir utiliser de limiteur de FPS.

Le nombre de FPS à soustraire est choisi pour vous. Dans mon cas ça verrouille à 138 FPS sur mon écran 144 Hz.

Par conséquent si ça vous épuise de devoir configurer des limites de FPS partout, vous pouvez juste activer AMD Anti-Lag ou Nvidia ULTRABASSE_LATENCE, activer vsync, et c'est tout bon.

...Sauf que ça fonctionne pas avec DirectX 12. Et Vulkan (Doom utilise Vulkan). Et OpenGL.

OK donc on est d'accord, l'utilité est toute relativement moyenne et proche du niveau de la mer.

De plus, des moins privilégiés du FPS que moi rapportent des saccades quand ces options sont activées. Je pense que je vais laisser ces options tranquillement désactivées, merci bien.

En règle générale, un ordinateur un peu faiblard ne gagnera absolument rien à activer ces options.

D'ailleurs, parlons-en:

Inverser la tendance: ajouter des buffers

On l'a déjà exposé: ajouter des framebuffers dans la swap chain rend les frametimes plus réguliers en appliquant un effet de moyenne sur le de temps de calcul des images.

Je peux pas trop en témoigner personnellement parce que ma machine est beaucoup trop OVERPOWERED et j'en ai pas d'autre pour tester. Oui, je suis triste aussi.

Par contre, j'ai vu un témoignage de quelqu'un qui possède une GTX 780ti et qui dit que ses jeux galèrent moins à tourner avec un nombre d'images pré-rendues de 2.

Il active aussi le mode basse latence mais à mon avis c'est pas ça qui fait la différence.

Rappelons encore un coup que le nombre d'images pré-rendues n'a pas d'effet sur les titres utilisant DirectX 12.

Du coup, je crois que je vais en parler dans la conclusion mais si votre ordi est un peu faible, pourquoi pas essayer d'augmenter la swap chain et voir si vous gagnez des FPS.

C'est aussi valide pour tout ce qui est "réalité virtuelle" où avoir un frametime stable est primordial.

Je pense que pour accomplir la même chose chez AMD is faut Radeon Pro.

Bonne chance à tous.

Nvidia Reflex

Okay donc les bidules DESTRUCTEURS d'INPUT LAG qui ont été abordés jusque maintenant ne fonctionne pas avec les jeux DirectX 12 (et Vulkan et OpenGL mais ça tout le monde s'en Pitch).

En effet, DirectX 12 a un système de génération d'images plus évolué avec un contrôle plus fin (et même multi-thread si j'ai bien compris) des files de rendu. Tripoter tout ça au niveau du pilote devient trop scabreux.

"Pas grave", se dit Nvidia. On va mettre notre machin directement dans le jeu.

Et c'est ça Reflex, la technologie doit être activement supportée par le jeu et est toujours une option qui est dans le jeu.

Elle permet, en gros, de créer une communication entre le moteur de jeu et l'état du 3D pipeline de sorte à paralléliser les bons éléments pour éviter au maximum qu'un maillon de la chaîne doive en attendre un autre. C'est assez velu et relativement peu de jeux supportent Reflex par extension.

Pour les quelques jeux qui le supportent, force est de constater que l'input lag baisse effectivement et en particulier dans des cas où la carte graphique est utilisée à son maximum.

Un moment je dois peut-être aussi rappeler que l'input lag c'est pas la mer à boire comme dirait ma mère.

Pour beaucoup de jeux, en particulier en solo et à la manette comme Witcher 3 ou Farming Simulator, l'input lag c'est pas vraiment un facteur.

Je disais quelque part plus haut qu'il y a des gens qui jouent dans le cloud avec un service comme Geforce NOW! ou Shadow qui ajoutent un gros délai d'aller-retour de paquets réseau en plus de tout le reste de l'input lag et beaucoup sont très contents comme ça.

Réduire l'input lag a plus de sens dans un contexte compétitif. Sauf que les joueurs hyper-compétitifs ils ont déjà un écran 360Hz, jouent en graphismes moyens ou minimum sur une faible résolutions et utilisent une limite très haute de FPS (ou aucune limite) avec un ordinateur capable de produire ces FPS de manière constante sans fatiguer et avec une carte graphique qui n'est pas en conditions d'utilisation maximale.

Ces gens sont déjà au minimum d'input lag. Activer Reflex dans un jeu ne change rien pour eux.

L'anti-lag/"low latency" ou Reflex qui est l'objet de cette section sont tous totalement inutiles pour ces cas de joueurs hyper compétitifs alors que beaucoup de joueurs moins compétitifs ne sont pas tout intéressés par l'input lag et sont de toutes façons dépassés par toutes ces options et n'ont aucune envie d'aller chipoter dans le "panneau de contrôle Nvidia" ou son équivalent AMD.

On est en droit de se demander à qui sont destinées ces options qui sortent alternativement chez Nvidia et AMD avec un florilège de marketing à grincer des dents.

Dans le cas de Reflex, exclusivité Nvidia et DirectX 12, c'est un peu différent parce que Reflex n'a (que je sache) pas d'inconvénients. Du coup on devrait l'activer d'office? Pourquoi c'est une option alors? Moi ça me fait peur je préfère pas l'activer. Mais je devrais. C'est terrible!

Tant que j'y suis, il y a deux niveaux de Reflex: le normal, et le boost.

Le second est censé augmenter la fréquence du GPU dans... Certains cas. D'après certaines sources ça n'a pratiquement aucun effet.

A mon avis le mode "boost" désactive certains mécanismes d'économie d'énergie. Ce n'est pas tant un "boost" qu'un mécanisme qui empêche de de-booster. On peut avoir l'impression que ça boost, mais en fait c'est juste resté au même niveau plutôt que de descendre.

Et AMD?

Apparemment ils bossent sur un truc un peu similaire qu'ils veulent appeler — accrochez-vous à votre siège gamer — HYPR-RX.

Censée sortir quelque part en 2023, cette technologie... Est juste Reflex mais pour AMD. Je vois pas ce que je peux dire de plus.

AMD prétend que ça va aussi augmenter les performances. Mouais. On verra 🩲😁

Conclusion

Maintenant que vous avez tout compris, une décision éclairée sur les meilleures options possibles est à portée de... Bras. Trop bien.

Pour les options recommandées, divisons la population en quelques catégories selon l'écran et si le matériel a du mal ou pas.

Je préface tout ceci en insistant que ces conseils ne sont valides que si le jeu est en mode "plein écran" (de préférence "exclusif").

Je post-préface encore un coup: la pérennité de ces recommandations n'est pas garantie. Le nom des options a déjà changé et il y en a tout le temps qui s'ajoutent.

Par exemple, Intel (qui débarque sur le marché des cartes graphiques) arrive avec "Speed Sync" (= fast/enhanced sync) et "Smooth Sync".

Peut-être je mettrai à jour la conclusion ou j'en parlerai dans des brèves.

Ecran compatible gsync/freesync

Premièrement: Activer gsync/freesync dans les pilotes graphiques et dans les menus de l'écran.

Secondement: Activer une limite FPS un peu en dessous de Vmax de l'écran (par ex. Vmax-4), dans le jeu si disponible et suffisamment flexible, sinon dans les pilotes (s'appelle Chill chez AMD).

Troisièmement: Activer Nvidia Reflex ou son équivalent-infernal-AMD-à-venir dans le jeu si proposé (en pratique c'est rare).

En option: Activez vsync pour retirer le peu de tearing qui reste selon votre préférence (tester avec et sans). Sur des écrans de taré de 240Hz+ le tearing est pratiquement invisible sans vsync — pour peu que votre combine ordinateur/jeu arrive à produire une telle quantité de FPS, bien entendu, c'est pas gagné.

Ecran/TV "old school" ou 4k 30/60 Hz avec matériel qui arrive à suivre

Quand je dis "matériel qui arrive à suivre", je veux dire que votre ordinateur est capable de produire au moins un nombre de FPS = V.

Je recommande de toutes manières d'essayer de toujours jouer dans ces conditions, en baissant éventuellement la résolution et les options graphiques pour y arriver. De nos jours on a aussi AMD FSR et Nvidia DLSS pour aider (FSR fonctionne sur toutes les cartes graphiques, merci AMD) à gagner des FPS au détriment d'une légère perte de qualité que je trouve personnellement tout à fait acceptable.

Quoi qu'il en soit, beaucoup de télévisions ou projecteurs ne supportent pas gsync/freesync ou bien vous n'avez pas le cable qu'il faut et en plus ils sont souvent en 60 Hz max, ce qui accentue le tearing et l'input lag par rapport à un écran à taux de rafraichissement plus élevé.

Selon la carte graphique et le cable, si vous jouez en 4k il y a beaucoup de chances que vous soyez limités à 30 ou 60 FPS. Il faut HDMI 2.1 (assez récent au niveau GPU) pour 4k 120 Hz.

Solution simple

Activez juste vsync. Dans le jeu ou dans le panneau de contrôle du pilote graphique (auquel cas il faut le désactiver dans le jeu).

L'input lag est significatif mais pour beaucoup de jeux c'est vraiment pas dérangeant. Pour certains individus c'est juste jamais dérangeant donc voilà, tranquille.

La plupart des consoles, surtout les anciennes, utilisent "bêtement" vsync. Le cloud gaming ajoute une latence élevée et ça se vend quand même.

Je pense qu'une partie de la tolérance des gens vient de l'absence d'expérience d'une machine puissante sur un écran gsync/freesync 144Hz+ dans sa plage de FPS optimale.

Quand vous avez eu cette expérience tout le reste a l'air un peu plus fade. Comme quand on rentre à la maison après une orgie. De raclette. Et qu'il n'y a qu'une lasagne Buitoni au cheval dans le surgé.

Parfois c'est bien de garder son innocence mais un écran freesync ça coûte pas si cher donc je suis pas certain de l'intérêt de poursuivre son voeu de pauvreté en 2023.

Solution pro

Utilisez le limiteur de FPS du pilote graphique — pas l'éventuel limiteur du jeu qui est moins précis, pour fixer une limite pile poil égale à V.

N'activez absolument rien d'autre, assurez-vous que vsync est désactivé.

Voilà c'est tout, y a plus qu'à tester.

Si ça vous va pas, vous pouvez essayer de limiter à V-1 ou appliquer la solution simple décrite ci-avant qui reste la meilleure alternative.

Ecran sans gsync/freesync et ordinateur en peine

Je vais pas vous mentir, ce combo est pas top et j'ai déjà recommandé plus haut de plutôt baisser les options graphiques pour essayer d'avoir des FPS>V.

Si c'est vraiment pas possible ou que vous avez pas envie parce que Nvidia vous a vendu que votre RTX 2060 allait être mieux qu'une 1660Ti parce qu'elle est capable de RayTracing et que vous avez 22 FPS dans Portal RTX et que vous êtes bien deg, je conseille de:

Premièrement: Tout de même poser un limiteur de FPS égal à V depuis les pilotes graphiques (pas dans le jeu).

Ensuite, plusieurs possibilités.

D'abord essayer d'augmenter la taille de la file de rendu (ne fonctionne pas sur DirectX 12 je rappelle) — C'est l'option préfixée de "Réalité virtuelle" dans le panneau de contrôle Nvidia (mais ça n'a rien à voir avec la réalité virtuelle) et c'est potentiellement planqué dans "Radeon Pro" (logiciel tiers) pour AMD.

Si c'est pas génial, vous pouvez remettre l'option par défaut pour les images pré-calculées et activer fast/enhanced sync depuis les pilotes graphiques. Le buffer supplémentaire devrait lisser l'expérience sans avoir les gros inconvénients de vsync quand les FPS varient beaucoup et sont inférieures à V.

Alternativement et comme d'hab vous pouvez aussi tester vsync seul, avec rien d'autre d'activé. Si ça vous plait, ben voilà. Jouissez-en avec allégresse.

Ecran avec gsync/freesync et ordinateur en peine

Très simple, premièrement activer gsync/freesync dans le panneau de contrôle des pilotes graphiques et dans les menus de l'écran (ben ça alors).

Deuxièmement: Fixer une limite de FPS de une ou deux FPS en dessous de V depuis les pilotes graphiques — Pas dans le jeu.

C'est tout. Joie et allégresse sont vôtres.

Si ça vous plait pas trop, je crains qu'une petite mise-à-jour de votre matériel s'impose et vous changera de catégorie dans ces recommandations mais cette situation devrait être tout à fait tolérable, et c'est une des grandes forces de gsync/freesync.

Le mode PRO GAMER

J'ai peu parlé de la solution la plus simple pour éviter les soucis liés à vsync: ne pas activer vsync, ni rien d'autre.

Pas de limite de FPS, pas d'anti-lag truc, des options graphiques faibles pour être certains qu'on a toujours des FPS bien plus élevées que V, et une Vmax élevée (240Hz+) sur l'écran principal.

La plupart activent tout de même gsync/vsync, mais pas nécessairement. Parce que c'est ça être une élite, payer pour de chouettes innovations technologiques mais jouer en qualité dégeu avec rien d'activé.

On obtient de cette manière l'input lag minimum, à bien sûr combiner avec des périphériques à haute fréquence de polling etc. Mais là on sort du cadre de cet article (ENFIN).

Au plus vous avez de FPS avec toutes les limites et vsync désactivés, au plus l'input lag baisse.

Je ne vous cache pas que ça commence à devenir absurde au delà des 300 FPS mais c'est un autre débat.

Et le tearing me dites-vous? Il est plus difficile à percevoir sur des écrans à V élevée et ces gens s'en balancent de toutes façons.

Obtenir les FPS les plus élevés possibles demande un processeur qui soit capable de suivre, à plus forte raison qu'une carte graphique de malade (ils jouent en qualité de merde de toutes façons) puisque la boucle de jeu doit tourner à une vitesse de barbare pour présenter toutes ces FPS.

Ceci explique le choix de processeurs extrêmement puissants en mono-tâche chez les PowER GamerZ alors que ce composant est moins important pour les gens... Normaux. Surtout par rapport à la carte graphique.