Lire le benchmark

Ce qu'il mesure

Les temps d'image du jeu auquel tu es réellement en train de jouer, lus depuis la pile graphique elle-même plutôt que depuis un overlay accroché au jeu. Tu lances la capture, tu joues normalement, tu l'arrêtes.

Jouer à ton propre jeu, ça compte. Une scène synthétique te dit comment la machine encaisse cette scène ; elle ne peut pas te dire si ton jeu saccade à l'endroit précis où il saccade toujours.

Les chiffres

Chiffre	Ce qu'il te dit
FPS moyen	le chiffre le moins utile ici. Deux machines avec la même moyenne peuvent donner une sensation totalement différente.
1% low	le pire 1 % des images. C'est ça, la sensation de saccade — une moyenne élevée avec un mauvais 1% low, c'est le classique « beaucoup de fps mais ça se joue mal ».
Temps d'image	les mêmes données en millisecondes. 16,7 ms, c'est 60 FPS ; 6,9 ms, c'est 144.

Lis les low, pas la moyenne. Passer de 200 à 210 de moyenne ne change rien que tu puisses sentir. Passer de 90 à 140 sur le 1% low change tout.

Comparer deux runs honnêtement

Même jeu, même carte, mêmes réglages, même durée de run.
Change une seule chose entre deux runs. Change-en trois et la comparaison ne te dit plus laquelle comptait.
Joue de la même manière. Un run passé à regarder un mur et un run passé en pleine fusillade ne sont pas comparables.

Ce qui est écarté

Les images que le jeu rend quand il n'est pas au premier plan ne sont pas comptées : les secondes entre le lancement de la mesure et le passage au jeu, les secondes après le retour pour l'arrêter, chaque alt-tab entre les deux et la première seconde après le retour du jeu au premier plan. Un jeu en arrière-plan rend souvent une fraction de sa cadence normale, et ces images suffisent à elles seules à fixer le 1% low. Le résultat indique combien de secondes ont été écartées, et une mesure enregistrée par un w0a plus ancien, qui les comptait encore, n'est pas jugée face à une plus récente.

Pourquoi les chiffres bougent d'un run à l'autre

Ils bougent toujours. La température, le travail en arrière-plan, l'endroit où tu as marché, ce qu'ont fait les autres joueurs. Quelques pour cent d'écart entre deux runs, c'est normal et ça ne prouve rien. Si un changement est réel, il revient à chaque fois et il se voit sur les low.

Après une mise à jour du pilote ou du jeu

Une paire prise de part et d'autre d'une mise à jour du jeu n'est pas jugée : la page nomme les deux versions et laisse l'écart sans couleur, comme elle le fait déjà pour un changement de pilote. Un patch change ce que fait le jeu lui-même, donc aucun écart de part et d'autre ne peut être attribué à un réglage. w0a lit la version dans les fichiers de Counter-Strike 2 ; pour les autres jeux, seul le pilote est comparé.

La première partie après une mise à jour du pilote ou du jeu peut compiler des shaders que le cache ne contient plus. Quand le premier run après la mise à jour la plus récente est sorti moins bon que le suivant sur les mêmes versions, de plus que le bruit propre aux deux runs, une note sous les résultats le dit. Rien ne mesure si la compilation des shaders en est la cause ; la note dit seulement que les deux concordent. Quand les deux runs ne diffèrent pas, il n'y a pas de note. Donc, après une mise à jour, joue une partie avant de mesurer et compare les réglages à partir du deuxième run.

Trancher avec une série A/B

Un seul run de chaque côté ne peut pas distinguer un petit changement de ces variations. Une série A/B répète la comparaison jusqu'à ce qu'elle le puisse. C'est toi qui décides ce que sont A et B (par exemple A : moteurs désactivés, B : activés) ; w0a ne modifie aucun réglage de lui-même.

D'abord le pilote. Appuie sur Lancer un pilote et mesure la même scène dix fois sans rien changer. Le pilote mesure de combien ton 1% low bouge d'un run à l'autre de lui-même et, à partir de là, la plus petite différence qu'une série peut voir. Il vaut pour le même jeu sur le même matériel.
Ensuite la série. Appuie sur Lancer une série A/B. Avant chaque mesure, la page indique le côté à mesurer, dans l'ordre A B B A, encore et encore. Passe à ce réglage, joue la même scène, arrête la mesure. Chaque B est comparé au A mesuré juste à côté, si bien que l'échauffement lent de la machine au fil de la soirée s'annule.
Chaque run est la même scène et dure au moins 100 secondes. Supprime le premier run après le lancement du jeu : les caches sont encore en train de chauffer.
Le verdict vient du seul 1% low, dès qu'il y a au moins six paires utilisables (huit, c'est mieux) ; les autres lignes sont informatives. Trois réponses doivent concorder : un test des rangs signés, un intervalle à 95 % de la médiane de la différence qui exclut zéro, et une différence au moins aussi grande que la plus petite que la série peut voir. Sans pilote, ou sans dix runs A dans la série pour en tenir lieu, une différence est affichée mais pas tranchée.
« Dans le bruit » est aussi un résultat : le changement n'a pas fait bouger les lows plus qu'ils ne bougent d'eux-mêmes.

Une paire que la carte de comparaison ne jugerait pas seule (un run trop court, des événements perdus, un moteur qui change d'état, un autre matériel) n'est pas comptée, et la série indique combien ont été écartées. Appuie sur Terminer la série quand tu as fini ; son résultat reste sur la page.

Combien de temps le jeu a attendu un processeur

Sous la liste des longs intervalles entre images, une carte lit pendant une courte fenêtre les propres enregistrements de l'ordonnanceur du noyau, une fois que le jeu présente des images depuis un moment : combien de temps les threads du jeu ont attendu entre le moment où ils étaient prêts à s'exécuter et celui où ils ont obtenu un processeur, et quels autres programmes tenaient le processeur entre-temps. Elle demande les droits d'administrateur, et une fenêtre où le noyau a perdu des événements n'affiche aucun chiffre plutôt qu'un chiffre faux. Avec deux runs sélectionnés, elle dit si l'attente a bougé plus que la dispersion propre des fenêtres.

La même carte indique le processeur sur lequel le thread le plus occupé du jeu (pris comme son thread principal) a le plus tourné, et le temps d'appels de procédure différés (DPC) mesuré là où il a tourné, à côté du processeur moyen. Une série ajoute une ligne : sur les runs d'un même réglage (le pilote ou le côté A), ce temps DPC et les saccades ont-ils monté et baissé ensemble ? Elle décrit seulement une coïncidence dans le temps ; ce qui cause quoi n'est pas mesuré.

Les runs enregistrés alimentent le scan des saccades

Les runs que tu enregistres servent de preuves au scan des saccades : les images nettement plus lentes que celles qui les entourent y apparaissent comme un constat à part entière, à côté des causes possibles. Un run enregistré sur le jeu qui saccade est la preuve la plus directe que tu puisses lui donner.