La fluidité n’est pas les FPS : le temps de trame expliqué en 2 minutes

Temps de trame en deux minutes (la seule définition qui compte)

Les FPS sont un débit : images par seconde. Le temps de trame est une durée : combien de temps une image a mis à être produite.
Votre cerveau perçoit la durée plus directement que le débit. Voilà toute l’histoire.
Le reste, ce sont des détails et de l’attribution de responsabilités.

Convertir les FPS en temps de trame

Temps de trame (millisecondes) ≈ 1000 / FPS.

• 60 FPS → ~16.67 ms par image
• 120 FPS → ~8.33 ms par image
• 144 FPS → ~6.94 ms par image
• 240 FPS → ~4.17 ms par image

Si chaque image arrive exactement toutes les 6,94 ms à 144 FPS, le mouvement paraît d’une fluidité parfaite.
Si la plupart des images arrivent toutes les 6–7 ms mais qu’une fois toutes les quelques secondes une image prend 40 ms, vous sentirez un accroc.
La moyenne des FPS peut rester « élevée ». Votre expérience, non.

Ce que signifie vraiment le graphique du temps de trame

Un graphique de temps de trame n’est qu’une chronologie de « combien de retard cette image avait ».
Une ligne plate, c’est bon. Des pics, c’est mauvais. Les motifs en dents de scie sont généralement des problèmes d’ordonnancement, de mise en file d’attente ou de synchronisation.
Des pics aléatoires éparpillés sont souvent du travail en arrière-plan (compilation, IO, GC, analyses antivirus, télémétrie, overlays).

« Mais mon compteur FPS indique 140 ! » Bien sûr. Si vous prenez 139 images à 7 ms et 1 image à 40 ms, la moyenne reste bonne.
Vos yeux se souviendront de la trahison à 40 ms.

Blague n°1 : les compteurs FPS sont comme des tableaux de bord trimestriels — excellents pour lisser la douleur jusqu’à ce que quelqu’un crie dans la réunion.

Pourquoi les FPS mentent (et pourquoi vos yeux ne mentent pas)

Les FPS sont typiquement échantillonnés et moyennés sur une fenêtre (parfois toute la seconde).
Le temps de trame est par image. C’est au niveau par-image que se loge la saccade.
Si vous dépannez un « ressenti étrange », vous ne voulez pas la moyenne. Vous voulez les pires moments.

Trois chiffres qui comptent plus que la moyenne des FPS

• 1% low FPS : le FPS aux 1% d’images les plus lentes. Meilleur indicateur de saccade que la moyenne.
• 0,1% low FPS : les 0,1% les plus lentes. Capture le problème « une fois par minute je subis un hitch ».
• Percentile du temps de trame : par ex. le 99e percentile du temps de trame. C’est « à quel point c’est mauvais ».

Ce que vous remarquez vraiment : la variance

Les humains détectent l’irrégularité. Un 60 FPS stable peut sembler plus fluide qu’un 90–180 FPS qui oscille fortement.
Le « ressenti » dépend surtout de la constance du pacing : l’uniformité du temps entre les images.

Pourquoi « plus de FPS » peut empirer la sensation

Des FPS non limités peuvent saturer le thread de rendu CPU, créer de plus grandes files d’attente et augmenter la latence. Alors vous obtenez :

• Plus de chaleur → throttling → pics périodiques du temps de trame
• Plus de contention → jitter d’ordonnancement du système d’exploitation
• Plus de consommation d’énergie → oscillations d’augmentation de fréquence GPU (surtout sur portable)
• Plus d’étrangetés de swapchain et de synchronisation → pacing irrégulier

Le compteur monte, le jeu semble pire, et vous commencez à vous auto-gaslighter. Ne le faites pas.
Limitez vos FPS à une valeur soutenable et observez le temps de trame s’aplanir.

Faits et histoire intéressants et utiles

1. Le VSync visait à l’origine le tearing, pas la « fluidité ». Il synchronise la présentation avec le rafraîchissement de l’écran,
   mais peut introduire des accrocs si des images manquent la deadline et attendent un cycle de rafraîchissement entier.
2. Les « 1% lows » sont devenus populaires parce que les moyennes cachaient les saccades. Les testeurs ont commencé à rapporter les bas niveaux une fois que le hardware haute performance
   a rendu la « moyenne » insignifiante pour la qualité perçue.
3. Les premiers jeux 3D étaient souvent limités par le CPU, pas par le GPU. Les transformations et l’éclairage étaient faites sur le CPU
   avant que les GPU ne prennent le relai, donc les patterns de saccade différaient : pics de simulation lourde plutôt que pics de shaders.
4. La compilation de shaders est une classique moderne de la saccade. Les moteurs qui compilent les shaders à la demande peuvent accrocher quand vous voyez un effet neuf.
   Le cache aide, mais seulement si le pipeline est implémenté et persistant correctement.
5. La VR a rendu le pacing indispensable. L’inconfort en VR a forcé l’industrie à considérer les deadlines ratées comme des échecs de première classe,
   pas comme une nuisance esthétique.
6. Des bugs de pacing existaient même quand les FPS étaient « corrects ». Certains anciens pilotes et moteurs produisaient une présentation inégale
   (le multi-GPU AFR était notoire), conduisant à du « microstutter » malgré une moyenne élevée d’images par seconde.
7. Les ordonnanceurs modernes d’OS peuvent créer du jitter sous charge. Tâches en arrière-plan, gestion d’énergie et tempêtes d’interruptions peuvent voler
   des tranches de temps au mauvais moment et apparaître comme des pics du temps de trame.
8. Le stockage est devenu rapide, mais les blocages IO n’ont pas disparu. Le NVMe a réduit les temps moyens de chargement, mais un IO bloquant sur le mauvais thread
   peut encore causer un accroc visible si le moteur n’est pas conçu pour streamer correctement.

Où le temps de trame meurt : schémas de goulot d’étranglement courants

La saccade est rarement « une seule chose ». C’est généralement un chemin critique qui bloque occasionnellement.
Pensez comme un SRE : nous ne corrigeons pas la « latence » en général. Nous corrigeons la latence de queue, et nous trouvons la dépendance qui en est responsable.

Limitation CPU : le thread principal est en retard

Symptômes : utilisation GPU faible ou fluctuante, un cœur CPU saturé, pics du temps de trame lors d’IA, physique, streaming du monde,
garbage collection, ou scènes avec beaucoup d’appels de rendu.

Approche pratique : réduire le coût de simulation, diminuer les draw calls, limiter les FPS, ou déplacer le travail hors du thread principal.
Si vous êtes joueur, vous ne pouvez pas réécrire le moteur, mais vous pouvez changer les réglages qui sollicitent le CPU : distance de vue, densité de foule,
physique/particules, constructions BVH de ray tracing (oui, ça peut aussi impacter le CPU).

Limitation GPU : le rendu est en retard

Symptômes : utilisation GPU élevée et stable, le temps de trame augmente avec la résolution et les effets lourds, les pics corrèlent avec explosions,
volumétrie, RT ou post-traitement. Le graphique peut aussi piquer si les fréquences sont bridées.

Approche pratique : réduire la résolution, désactiver d’abord les effets coûteux (RT, volumétrie, ombres), utiliser DLSS/FSR/XeSS si disponible,
et éviter les FPS non limités s’ils provoquent un throttling thermique.

Pacing / problèmes de synchronisation : le pipeline est inégal

Symptômes : FPS moyen élevé, mais le graphique du temps de trame montre des pics périodiques à intervalle régulier (par ex. chaque seconde ou multiple de rafraîchissement).
Souvent lié à VSync, triple buffering, mode fenêtré sans bordure, overlays, logiciels de capture, ou limiteurs de trame défaillants.

IO et stockage : l’accroc que vous ne pouvez pas « régler avec les graphismes »

Symptômes : pics en entrant dans de nouvelles zones, en tournant rapidement, en ouvrant des menus, ou après de longues sessions.
La file d’attente disque monte, les défauts de page augmentent, et le système devient « collant » entre les applications.

Causes : stalls de streaming d’actifs, écritures du cache de shaders, RAM insuffisante conduisant au paging, analyses antivirus scannant les fichiers du jeu,
ou un disque effectuant une maintenance en arrière-plan. Un stockage rapide aide, mais une mauvaise architecture de threads rend le stockage rapide inutile.

Réseau et tick serveur : les jeux en ligne peuvent aussi saccader

Toute « saccade » n’est pas du temps de trame. La perte de paquets et le jitter réseau peuvent ressembler à des accrocs car le mouvement du joueur saute ou subit des rubber-bands.
Distinguez la saccade de rendu (pics du temps de trame) de la saccade simulation/réseau (temps de trame stable, mais mouvement incohérent).

Méthode de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Quand vous êtes sous pression — nuit de tournoi, démo pour la direction, « pourquoi cette station de travail est lente » — vous avez besoin d’un triage.
C’est le chemin le plus court vers une réponse utile.

Premier : confirmez que c’est le temps de trame, pas le réseau ou la perception

1. Activez un graphique du temps de trame (in-game, overlay ou outil de capture).
2. Reproduisez l’accroc trois fois au même endroit/action.
3. Si le graphique pique avec l’accroc : c’est la latence de rendu/simulation. Sinon : suspectez le réseau ou l’entrée.

Deuxième : décidez si vous êtes limité par le CPU ou le GPU

1. Surveillez l’utilisation GPU et les fréquences pendant l’accroc.
2. Si l’utilisation GPU est faible quand le temps de trame est élevé : CPU ou stall de synchronisation/pilote.
3. Si l’utilisation GPU est saturée et que le temps de trame augmente avec la résolution : limité par le GPU.

Troisième : éliminez la « sabotage externe »

1. Désactivez les overlays (capture, chat, performance, logiciels RGB).
2. Vérifiez les tâches en arrière-plan : analyses antivirus, mises à jour, indexation, télémétrie.
3. Vérifiez la santé du stockage et le paging : RAM basse et défauts de page sont des usines à hitch.

Quatrième : appliquez les stabilisateurs les plus rapides

• Limitez les FPS (limiteur intra-jeu recommandé). Cible : légèrement en dessous du rafraîchissement (par ex., 141 sur 144 Hz).
• Activez le VRR (G-Sync/FreeSync) si supporté ; utilisez-le avec des limites raisonnables.
• Choisissez un plan d’alimentation qui ne réduit pas excessivement la fréquence lors de charges transitoires.

Si vous effectuez ces quatre étapes et que des pics subsistent, vous n’êtes pas « en train de rater un réglage ». Vous avez affaire à un problème de contenu/moteur/pilote,
ou à une instabilité matérielle/OS. C’est alors que vous collectez des preuves au lieu de bidouiller des cases à cocher sans méthode.

Tâches pratiques : 14 commandes réelles, ce qu’elles signifient, ce que vous décidez

Celles-ci sont écrites comme un runbook SRE parce que c’est cela, le dépannage de performance : un incident avec des graphiques,
des hypothèses et du confinement. La plupart des commandes sont orientées Linux parce qu’elles sont reproductibles et honnêtes.
Si vous êtes sous Windows, le modèle mental reste applicable : vous cherchez la saturation CPU, les stalls GPU, la mise en file IO et la pression mémoire.

Tâche 1 : Confirmer le taux de rafraîchissement et le mode courant

cr0x@server:~$ xrandr --current
Screen 0: minimum 8 x 8, current 2560 x 1440, maximum 32767 x 32767
DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 596mm x 335mm
   2560x1440     143.91*+
   1920x1080     143.85
HDMI-1 disconnected (normal left inverted right x axis y axis)

Ce que ça signifie : Vous êtes effectivement à 143,91 Hz sur DP-1. Bien.
Si vous pensiez être à 144 Hz mais que vous êtes à 60 Hz, aucun réglage ne corrigera le « ressenti lent ».

Décision : Si le rafraîchissement est incorrect, corrigez les paramètres d’affichage/câble/port avant de toucher autre chose.

Tâche 2 : Vérifier le chemin du compositeur / VSync (indice Wayland/X11)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Ce que ça signifie : Vous êtes sur Wayland. Certains jeux et overlays se comportent différemment ; les outils de capture et les compositeurs peuvent ajouter de la latence ou des artefacts de pacing.

Décision : Si la saccade est apparue après un changement de type de session, testez l’autre type de session comme contrôle.

Tâche 3 : Pression CPU en direct et saturation par cœur

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (host) 	01/13/2026 	_x86_64_	(16 CPU)

12:10:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:10:02 AM  all   28.10  0.00  6.20   0.15 0.00  0.35   0.00 65.20
12:10:02 AM    0   92.00  0.00  5.00   0.00 0.00  0.00   0.00  3.00
12:10:02 AM    1   18.00  0.00  4.00   0.00 0.00  0.00   0.00 78.00

Ce que ça signifie : CPU0 est presque saturé tandis que les autres sont plutôt au repos. Ça crie « thread principal lié ».

Décision : Réduisez les réglages lourds en CPU, limitez les FPS, et vérifiez les interruptions de fond ou un goulot mono-thread.

Tâche 4 : Confirmer la pression mémoire (le paging cause des accrocs)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        27Gi       1.2Gi       1.1Gi       3.0Gi       2.8Gi
Swap:           16Gi       7.8Gi       8.2Gi

Ce que ça signifie : Le swap est utilisé activement. Pas forcément fatal, mais l’utilisation du swap pendant le jeu est une cause classique de saccades.

Décision : Fermez les applications gourmandes en mémoire, réduisez la qualité des textures, ou ajoutez de la RAM. Si le swap augmente pendant le jeu, traitez-le comme un incident réel.

Tâche 5 : Surveiller les défauts majeurs de page en temps réel

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 812345 1213456 102400 2800000  15   22   120   340 5200 8800 31  7 60  2  0
 3  1 813112 1189000 102400 2792000  80  110   900  1400 6400 9900 35  8 52  5  0

Ce que ça signifie : Des valeurs non nulles pour si/so signifient des échanges de swap in/out. C’est de l’IO sur votre chemin mémoire.

Décision : Si l’activité de swap corrèle avec les accrocs, cessez de traiter les réglages graphiques comme la cause.

Tâche 6 : Identifier la mise en file IO et la saturation disque

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (host) 	01/13/2026 	_x86_64_	(16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1          12.0    85.0   640.0  8200.0   6.50  78.00
sda               0.0     2.0     0.0    64.0  25.00   5.00

Ce que ça signifie : Le NVMe est occupé (%util élevé). await ~6,5 ms est correct, mais les pics comptent.
Si vous voyez await sauter dans les dizaines/centaines de ms pendant les accrocs, l’IO est impliqué.

Décision : Si l’IO est saturée, déplacez le jeu sur un stockage plus rapide, excluez-le des analyses AV, et vérifiez les écritures en arrière-plan.

Tâche 7 : Rechercher des pics de latence au niveau système de fichiers et bloc

cr0x@server:~$ sudo dmesg -T | tail -n 8
[Tue Jan 13 00:11:02 2026] nvme nvme0: I/O 123 QID 5 timeout, aborting
[Tue Jan 13 00:11:02 2026] nvme nvme0: Abort status: 0x371
[Tue Jan 13 00:11:03 2026] EXT4-fs warning (device nvme0n1p2): ext4_end_bio:343: I/O error 10 writing to inode 262145 starting block 12345678

Ce que ça signifie : Ce n’est pas juste de la « saccade », c’est un incident de stockage. Les timeouts et erreurs IO se manifesteront par des accrocs sévères et éventuellement une perte de données.

Décision : Arrêtez les benchmarks. Sauvegardez les données. Vérifiez SMART, les câbles, les températures, le firmware.

Tâche 8 : Vérifier SMART NVMe et indicateurs de throttling thermique

cr0x@server:~$ sudo smartctl -a /dev/nvme0
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning:                   0x00
Temperature:                       79 Celsius
Available Spare:                   100%
Percentage Used:                   6%
Data Units Read:                   12,345,678
Data Units Written:                9,876,543
Warning Comp. Temperature Time:    0
Critical Comp. Temperature Time:   12

Ce que ça signifie : 79°C et un temps non nul dans « critical temperature time » suggèrent des événements de throttling.
Le throttling peut créer des pics périodiques du temps de trame dus à l’explosion de la latence IO.

Décision : Améliorez le flux d’air, ajoutez un dissipateur, repositionnez le disque, mettez à jour le firmware si nécessaire.

Tâche 9 : Confirmer le pilote GPU et statistiques GPU de base (exemple NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,driver_version,utilization.gpu,clocks.sm,temperature.gpu,pstate --format=csv
name, driver_version, utilization.gpu [%], clocks.sm [MHz], temperature.gpu, pstate
NVIDIA GeForce RTX 4070, 550.54.14, 96 %, 2475 MHz, 73, P0

Ce que ça signifie : Le GPU est presque saturé et en P0 (état de performance max). Probablement limité par le GPU à cet instant.

Décision : Si le temps de trame est élevé ici, baissez les réglages coûteux en GPU ou utilisez un upscaler.

Tâche 10 : Vérifier les raisons de throttling GPU (NVIDIA)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,80p'
==============NVSMI LOG==============
Performance State                          : P0
Clocks Throttle Reasons
    Idle                                   : Not Active
    Applications Clocks Setting             : Not Active
    SW Power Cap                            : Not Active
    HW Slowdown                             : Active
    HW Thermal Slowdown                     : Active
    Sync Boost                              : Not Active
    SW Thermal Slowdown                     : Not Active

Ce que ça signifie : Un ralentissement thermique est actif. Votre GPU freine par intermittence.
Cela produit un motif très spécifique : « tourne bien, puis accrocs ».

Décision : Corrigez le refroidissement, réduisez légèrement la limite de puissance, ou limitez les FPS pour réduire la chaleur sans tuer la réactivité.

Tâche 11 : Attraper les processus CPU en arrière-plan lors d’un accroc

cr0x@server:~$ top -b -n 1 | head -n 20
top - 00:12:44 up  2:31,  1 user,  load average: 4.21, 3.88, 3.51
Tasks: 329 total,   2 running, 327 sleeping,   0 stopped,   0 zombie
%Cpu(s): 36.3 us,  7.2 sy,  0.0 ni, 55.8 id,  0.5 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :  32154.0 total,   1204.0 free,  27680.0 used,   3270.0 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 8421 cr0x      20   0  9812m  5020m  132m R  168.0  15.6  12:31.22 game.bin
 2210 root      20   0  1240m  220m   34m S   45.0   0.7   0:40.11 tracker-miner-fs

Ce que ça signifie : Le jeu est occupé (attendu), mais un indexeur de système de fichiers l’est aussi. C’est un complice des saccades.

Décision : Mettez en pause/désactivez l’indexation pour l’emplacement de la bibliothèque de jeux. Si c’est géré par la DSI, demandez une exclusion.

Tâche 12 : Vérifier les tempêtes d’interruptions (lag d’entrée et pics)

cr0x@server:~$ cat /proc/interrupts | head
           CPU0       CPU1       CPU2       CPU3
  0:         45          0          0          0   IO-APIC   2-edge      timer
  1:          2          0          0          0   IO-APIC   1-edge      i8042
 24:    1423456    1322211    1209987    1187765   PCI-MSI 327680-edge      nvme0q0
 42:     983221     964112     955001     948887   PCI-MSI 524288-edge      nvidia

Ce que ça signifie : Des taux d’interruption élevés sont normaux pour NVMe/GPU, mais si un CPU est noyé alors que d’autres sont au repos,
vous pouvez avoir du jitter d’ordonnancement.

Décision : Si vous voyez un déséquilibre pathologique ou des sauts soudains, investiguez sur les pilotes, les réglages MSI/MSI-X, ou des régressions du noyau.

Tâche 13 : Vérifier la mise à l’échelle de la fréquence CPU (pics de sous-fréquence)

cr0x@server:~$ grep -H . /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000

Ce que ça signifie : Le gouverneur est powersave et le CPU est à 800 MHz en ce moment.
C’est excellent pour l’autonomie et terrible pour les pics de temps de trame.

Décision : Passez à un gouverneur orienté performance pendant le jeu ou pour les charges sensibles à la latence.

Tâche 14 : Appliquer un gouverneur de performance temporaire (tester, ne pas « régler et oublier »)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
Setting cpu: 8
Setting cpu: 9
Setting cpu: 10
Setting cpu: 11
Setting cpu: 12
Setting cpu: 13
Setting cpu: 14
Setting cpu: 15

Ce que ça signifie : Vous avez supprimé une source majeure de variance de latence : les sous-fréquences agressives.

Décision : Si cela améliore le pacing, créez une solution par profil (mode jeu) plutôt que de laisser la machine chauffée en permanence.

Trois mini-récits d’entreprise issus du terrain

1) L’incident causé par une mauvaise hypothèse : « Les FPS sont élevés, donc la station est OK »

Une équipe de design s’est plainte que leur vue 3D « semblait collante » sur des stations de travail neuves et haut de gamme.
L’informatique a répondu par l’évidence : « Le GPU est top ; le compteur affiche plus de 120 ; ce n’est pas la machine. »
Le ticket a été renvoyé deux fois. Le moral n’a pas augmenté d’un pourcent.

Un ingénieur avec l’esprit SRE s’est assis avec un utilisateur et a fait la chose ennuyeuse : il a regardé le temps de trame, pas les FPS.
Le graphique était plat jusqu’à ce qu’ils ouvrent un panneau lourd de navigateur d’actifs, puis il piquait toutes les quelques secondes comme un métronome.
Ce n’était pas un accroc aléatoire. C’était un stall périodique.

Ils ont corrélé les pics avec l’activité disque. Il s’est avéré que le répertoire de cache d’actifs était sur un dossier synchronisé en réseau
imposé par la politique. L’agent de synchronisation se réveillait périodiquement, scannait une pile de petits fichiers, et entrait en contention avec l’IO de l’application.
La moyenne des FPS restait élevée parce que le rendu fonctionnait entre les stalls. L’expérience utilisateur, non.

La solution n’était pas « plus de GPU ». C’était déplacer le cache sur un NVMe local et l’exclure de la synchronisation,
tout en gardant les fichiers de projet finaux synchronisés. Les pics de temps de trame ont disparu.
Le postmortem disait crûment : arrêtez d’utiliser les FPS comme proxy de la réactivité.

2) L’optimisation qui a échoué : courir après des FPS de pointe et acheter des saccades

Une petite équipe interne gérait un mur de visualisation pour une salle de briefing client. Quelqu’un a remarqué que l’application passait parfois sous le rafraîchissement de l’écran.
Un ingénieur bien intentionné a « optimisé » en débloquant les FPS et en désactivant la synchronisation pour « laisser le GPU tourner librement ».
Le compteur FPS a grimpé. L’équipe s’est applaudie en interne. Puis les clients ont demandé pourquoi le mouvement semblait saccadé.

Le problème n’était pas le débit brut ; c’était le pacing. Le rendu non limité a créé une file d’images profonde.
La latence input-to-photon a augmenté, et l’écran a vu une livraison inégale parce que le compositeur et la swapchain jonglaient désormais avec un flot d’images.
De petits stalls périodiques (garbage collection, vidage de logs, télémétrie) sont devenus visibles comme des accrocs durs parce qu’il n’y avait plus de cadence cohérente.

Le plus humiliant : « l’optimisation » a aussi augmenté la thermique. Après quinze minutes, le GPU a throttlé.
Le temps de trame a fortement piqué juste au moment du « moment wow » de la présentation.

La correction fut contre-intuitive pour les adeptes du « plus de FPS » : limiter les FPS légèrement sous le rafraîchissement, activer le VRR si possible, et garder le buffering prévisible.
Les FPS de pointe ont diminué. La fluidité s’est améliorée. Les clients ont arrêté de plisser les yeux.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : triage performance fondé sur des preuves

Une équipe de production responsable d’un simulateur de formation avait un candidat de release qui « semblait pire » que la build précédente.
Pas de crashs, pas de régressions évidentes dans les FPS moyens. Juste un ressenti pervasive de saccades en se déplaçant rapidement dans un environnement complexe.
La voie facile aurait été de débattre des opinions. La voie correcte fut de collecter des traces cohérentes.

Ils ont gardé une checklist standard de capture de performance : même itinéraire, mêmes balayages caméra, mêmes presets graphiques, même état machine.
Ils ont capturé les temps de trame, l’utilisation CPU/GPU, et les stats IO. Puis ils ont comparé les percentiles, pas les moyennes.
La régression est apparue comme un pire 99,9e percentile du temps de trame, même si la moyenne des FPS restait inchangée.

Le coupable était banal : un changement de logging qui vidait sur disque plus fréquemment, et sur le thread principal.
Sur des machines rapides c’était « acceptable », jusqu’à ce que le système de fichiers effectue un sync périodique ou que le disque chauffe et que la latence explose.
Le logging n’était pas « lourd » en moyenne ; il bloquait occasionnellement.

Ils ont déplacé le logging hors du thread principal et effectué des flushs par lots de manière sûre. La release est partie à l’heure.
Personne n’a posté un message héroïque sur Slack, ce qui est la preuve que c’était bien fait.

Erreurs courantes : symptôme → cause racine → correctif

1) « FPS élevés mais ça saccade quand je tourne rapidement »

Symptôme : Pics lors des panoramiques caméra, en entrant dans de nouvelles zones, ou lors d’effets vus pour la première fois.

Cause racine : Stalls de streaming d’actifs ou compilation de shaders à la demande.

Correctif : Activez la pré-compilation des shaders si disponible, réchauffez le cache de shaders, déplacez le jeu sur un stockage rapide, évitez l’IO en arrière-plan, conservez une marge de RAM.

2) « C’est fluide pendant 10 minutes, puis ça empire »

Symptôme : Les pics du temps de trame augmentent avec le temps.

Cause racine : Throttling thermique (GPU/CPU/NVMe) ou fuite mémoire menant au paging.

Correctif : Surveillez fréquences/temps, améliorez le refroidissement, limitez les FPS, vérifiez la RAM et l’activité swap, redémarrez comme containment si nécessaire.

3) « Accroc périodique toutes les secondes (ou toutes les quelques secondes) »

Symptôme : Pics du temps de trame à cadence régulière.

Cause racine : Tâches planifiées en arrière-plan (indexeurs, mises à jour), vidage de télémétrie, ou désynchronisation/buffering avec la cadence de rafraîchissement.

Correctif : Désactivez les tâches planifiées, testez le plein écran exclusif, utilisez une limite FPS raisonnable, et évitez les limiteurs tiers qui causent du jitter de pacing.

4) « Activer VSync le rend lent ; le désactiver découpe l’image »

Symptôme : Soit du tearing, soit une saisie collante.

Cause racine : Comportement classique du VSync : rater une deadline force l’attente d’un rafraîchissement complet ; le buffering ajoute de la latence.

Correctif : Utilisez le VRR si disponible ; limitez les FPS légèrement sous le rafraîchissement ; si vous êtes contraint au VSync, ajustez les réglages pour éviter de rater les deadlines.

5) « Baisser les graphismes n’aide pas les saccades »

Symptôme : Mêmes pics aux réglages bas.

Cause racine : Thread principal lié au CPU, stalls IO, ou interruptions côté OS.

Correctif : Réduisez les réglages gourmands en CPU, vérifiez les processus en arrière-plan, confirmez la pression mémoire, et arrêtez de blâmer le GPU par défaut.

6) « Microstutter uniquement en fenêtré sans bordure »

Symptôme : Le plein écran semble plus fluide que le mode sans bordure.

Cause racine : Le chemin du compositeur ajoute de la complexité d’ordonnancement et de buffering ; les overlays s’accrochent différemment.

Correctif : Essayez le plein écran exclusif, désactivez les overlays, testez différents réglages du compositeur ou type de session.

7) « Saccade après une mise à jour du pilote »

Symptôme : Nouveaux pics ou pire pacing après une mise à jour.

Cause racine : Régression du pilote, invalidation du cache de shaders, ou changement des valeurs par défaut de gestion d’énergie.

Correctif : Installation propre du pilote, reconstruire le cache de shaders, vérifier le comportement des fréquences/puissance, et revenir en arrière si les preuves le justifient.

Blague n°2 : si votre correctif implique « essayez de réinstaller Windows », ce n’est pas du dépannage ; c’est un exorcisme de performance avec une barre de progression.

Listes de contrôle / plan étape par étape

Checklist A : stabiliser le pacing en 15 minutes

1. Mesurer : activez un graphique du temps de trame et reproduisez l’accroc de manière fiable.
2. Limiter les FPS : utilisez le limiteur intra-jeu d’abord ; réglez la limite à rafraîchissement-3 (par ex. 141 pour 144 Hz).
3. VRR : activez G-Sync/FreeSync ; gardez la limite pour rester dans la fenêtre VRR.
4. Overlays désactivés : désactivez les outils de capture/overlay un par un ; retestez après chaque changement.
5. Thermiques : surveillez les fréquences/temps GPU/CPU ; corrigez le throttling avant de chasser les réglages.
6. Marge mémoire : assurez-vous d’avoir de la RAM disponible ; fermez navigateurs et launchers qui gonflent dans le temps.
7. IO sain : assurez-vous que le jeu est sur un stockage local rapide ; excluez-le de l’analyse en temps réel si la politique le permet.

Checklist B : décider « CPU-bound vs GPU-bound » sans deviner

1. Baissez la résolution d’un cran (ou activez un upscaler).
2. Si les temps de trame s’améliorent significativement : plutôt GPU-bound.
3. Si les temps de trame changent à peine : plutôt CPU-bound ou IO/sync-bound.
4. Baissez les réglages lourds en CPU (distance de vue/foules/physique).
5. Si les temps de trame s’améliorent : CPU-bound confirmé.

Checklist C : paquet de preuves pour escalade (pilote/fournisseur/équipe moteur)

• Capture de temps de trame montrant les pics (inclure les stats de percentiles si possible).
• Fréquences/temps/utilisation GPU au moment des pics.
• Utilisation CPU par cœur et état de scaling de fréquence.
• Stats IO (file d’attente/await) et stats mémoire (swap/défauts de page).
• Étapes exactes de reproduction (scène, itinéraire, réglages, temps jusqu’à la défaillance).

Une note de fiabilité à reprendre pour vos propres systèmes

« La latence moyenne rassure. La latence tail est l’expérience client. » C’est la même leçon que pour le temps de trame.
En exploitation, nous suivons p95/p99. En rendu, nous suivons les 1% et 0,1% lows et les pics du temps de trame.

Une citation, parce qu’elle est pertinente et utile à retenir :
Tout échoue tout le temps. — Werner Vogels

FAQ

1) Si j’ai un écran 240 Hz, ai-je besoin de 240 FPS ?

Non. Vous avez besoin d’une livraison constante. 120 FPS avec des temps d’environ 8,3 ms et plats peut sembler mieux qu’un 200–240 instable.
Un rafraîchissement plus élevé aide à réduire la latence perçue, mais seulement si votre système tient des temps de trame stables.

2) Quelle est la différence entre « saccade » et « input lag » ?

La saccade est un temps de trame inégal (accrocs visuels). L’input lag est le temps entre votre action et les photons à l’écran.
Ils sont corrélés mais pas identiques : vous pouvez avoir un pacing lisse avec une latence élevée (files profondes),
ou une faible latence avec des pics occasionnels (stalls en arrière-plan).

3) Les 1% lows sont-ils la même chose que les pics de temps de trame ?

Ils sont liés. Les 1% lows résument les 1% d’images les plus lentes dans un seul nombre.
Les graphiques de temps de trame montrent la forme et le timing exacts. Utilisez les lows pour des comparaisons rapides ; utilisez les graphiques pour le diagnostic.

4) Pourquoi une limite de FPS rend parfois le jeu plus fluide ?

Parce qu’elle réduit la variance et empêche l’accumulation incontrôlée de files d’images et l’oscillation thermique.
Une limite force le pipeline dans une cadence prévisible. Une cadence prévisible paraît fluide.

5) Dois-je utiliser le limiteur intra-jeu, celui du pilote, ou un outil externe ?

Préférez l’in-game d’abord. Il est le plus proche du modèle de timing du moteur et produit généralement un meilleur pacing.
Les limites au niveau pilote peuvent convenir. Les outils externes varient énormément ; certains sont excellents, d’autres introduisent du jitter. Mesurez, n’assumez pas.

6) Une RAM plus rapide aide-t-elle le temps de trame ?

Parfois, surtout en scénarios limités par le CPU où le thread principal est sensible à la latence mémoire.
Mais ce n’est rarement une solution miracle. Si vous swappez sur disque, une RAM plus rapide ne vous sauvera pas. Corrigez d’abord la pression mémoire.

7) Pourquoi je saccade seulement la première fois que j’entre dans une zone ?

C’est souvent la compilation de shaders ou le warm-up du cache d’actifs. Une fois compilé/caché, les répétitions sont plus fluides.
Les jeux qui précompilent les shaders au démarrage accrochent moins en jeu, au prix de temps de chargement plus longs.

8) Le stockage peut-il vraiment causer des saccades en jeu même sur NVMe ?

Oui. Le NVMe améliore les moyennes, pas l’architecture. Un IO synchrone unique sur un thread critique peut bloquer l’image.
De plus : le throttling thermique ou des problèmes de firmware peuvent faire exploser la latence IO. Vérifiez SMART et les températures si le motif correspond.

9) Le VRR (G-Sync/FreeSync) est-il toujours mieux ?

Généralement, pour des rates variables. Mais le VRR ne corrige pas les énormes pics ; il adapte juste le rafraîchissement à la livraison des images.
Vous devez toujours éliminer les stalls. De plus, un VRR mal configuré avec de mauvaises limites peut causer des scintillements ou un pacing étrange.

10) Quel temps de trame est « bon » ?

Atteignez votre cible. Pour 60 Hz, vous voulez la plupart des images sous 16,67 ms, avec un minimum de pics.
Pour 144 Hz, visez ~6,94 ms typique et resserrez la queue — des pics au-dessus de ~20 ms seront visibles en mouvement rapide.

Conclusion : prochaines étapes qui font réellement la différence

Arrêtez de vous battre avec un compteur FPS. Mesurez le temps de trame.
L’objectif n’est pas un chiffre de pointe héroïque ; c’est la constance ennuyeuse.
L’ennuyeux est fluide. La fluidité est ce que vous vouliez.

Faites ceci ensuite, dans l’ordre

1. Activez un graphique de temps de trame et reproduisez le problème.
2. Limitez les FPS légèrement sous le rafraîchissement et testez à nouveau.
3. Classifiez le goulot : CPU, GPU, IO/mémoire ou sync/pacing.
4. Éliminez les coupables en arrière-plan (overlays, indexeurs, mises à jour) et vérifiez les thermiques.
5. Si des pics restent, collectez un paquet de preuves (percentiles, fréquences, températures, IO, mémoire) et escaladez avec des données.

Voilà toute la doctrine du temps de trame. Pratiquez-la pendant une semaine et vous commencerez à entendre les problèmes de saccade en réunion
comme vous entendez la latence tail en production : comme un problème de dépendance résoluble, pas comme « mon PC me déteste ».