Un compteur de FPS peut afficher 60, 90 ou 144 images par seconde et donner malgré tout l’impression que le jeu accroche. Le problème n’est pas forcément le nombre moyen d’images produites. Il peut venir de leur régularité.
Une seconde composée de nombreuses images rapides et de quelques images très lentes conserve parfois une moyenne flatteuse. À l’écran, les pointes lentes se ressentent comme des à-coups, surtout pendant un déplacement de caméra ou une action précise.
Avant de remplacer la carte graphique, d’installer un « optimiseur » ou de modifier dix réglages Windows, je préfère rendre le problème mesurable. L’objectif n’est pas de fabriquer un score de benchmark. Il est de relier un symptôme visible à une hypothèse que l’on peut tester.
La distinction vaut aussi pour les démonstrations officielles : mon analyse de ce que « images tirées du jeu » confirme réellement pour GTA VI sur PS5 explique pourquoi une séquence choisie ne remplace ni un test reproductible, ni une mesure du frametime.
La réponse courte
Pour diagnostiquer des saccades, il faut enregistrer la durée de chaque image, reproduire le même passage et ne modifier qu’un élément à la fois.
À 60 images par seconde, une image dispose d’environ 16,7 millisecondes. À 120 images par seconde, le budget descend à environ 8,3 ms. Une moyenne de 60 FPS ne dit pas si certaines images ont demandé 40, 80 ou 200 ms.
La méthode tient en six étapes :
- décrire exactement le type de saccade ;
- choisir une scène courte et reproductible ;
- enregistrer le frametime avec un outil identifié ;
- vérifier les conditions du test ;
- modifier une variable ;
- refaire plusieurs passages avant de conclure.
Commencer par décrire la saccade
« Le jeu rame » recouvre des problèmes très différents.
- Une saccade unique au premier passage dans une zone peut correspondre à une compilation, un chargement ou une mise en cache.
- Un à-coup qui revient toutes les quelques secondes peut suivre une tâche périodique, une sauvegarde, un outil de capture ou une saturation de mémoire.
- Une dégradation progressive après plusieurs minutes peut orienter vers la température, une fuite de mémoire ou une accumulation de données.
- Un mouvement de caméra irrégulier malgré un jeu stable peut dépendre de la synchronisation, du périphérique d’entrée ou du rythme d’affichage.
- Une chute toujours déclenchée par le même effet visuel aide à construire un scénario reproductible.
Je note aussi ce qui a changé juste avant l’apparition du problème : pilote, mise à jour du jeu, nouveau mod, changement d’écran, réglage graphique, logiciel en arrière-plan ou déplacement du jeu vers un autre stockage.
Cette chronologie évite de confondre une coïncidence avec une cause.
FPS et frametime ne racontent pas la même histoire
Le nombre d’images par seconde est un débit. Le frametime est une durée.
La conversion théorique est simple : 1000 / FPS = millisecondes par image.
| Objectif | Budget approximatif par image |
|---|---|
| 30 FPS | 33,3 ms |
| 60 FPS | 16,7 ms |
| 90 FPS | 11,1 ms |
| 120 FPS | 8,3 ms |
| 144 FPS | 6,9 ms |
Ces valeurs ne constituent pas une promesse de fluidité. Elles donnent une échelle. Une série proche de 16 à 17 ms sera généralement plus régulière qu’une alternance entre 8 ms et 35 ms produisant une moyenne comparable.
Il faut aussi distinguer l’image rendue par l’application, l’image présentée au système et l’image réellement affichée. La génération d’images par un pilote ou un moteur complique encore la lecture. C’est pour cela que je note le nom exact de la métrique utilisée au lieu d’écrire seulement « frametime ».
Construire une scène de test utile
Un benchmark intégré est pratique, mais il ne reproduit pas toujours le passage qui gêne réellement. À l’inverse, jouer au hasard pendant vingt minutes produit trop de variations.
Je choisis une séquence de trente à soixante secondes :
- le même point de départ ;
- le même trajet ;
- des réglages identiques ;
- le même mode plein écran ou fenêtré ;
- le même plafond d’images ;
- le même état de chargement de la sauvegarde ;
- si possible, une situation hors ligne ou peu dépendante d’autres joueurs.
Je fais un passage d’échauffement, puis au moins trois captures. Le premier lancement peut inclure des opérations qui ne se répéteront pas de la même manière. Le noter vaut mieux que l’effacer parce qu’il donne un résultat moins joli.
Mesurer avec PresentMon
PresentMon est un projet libre maintenu par Intel pour capturer et analyser les événements de présentation sous Windows. Il prend en charge plusieurs API graphiques et peut produire un fichier CSV contenant des mesures par image.
La version graphique Intel PresentMon propose un overlay et des captures. La version console expose davantage d’options. Dans les deux cas, je télécharge l’outil depuis la page officielle Intel ou le dépôt officiel, jamais depuis un site de téléchargement qui republie l’exécutable.
La documentation distingue notamment :
- le temps entre deux appels de présentation ;
- le temps CPU consacré à une image ;
- le temps ou l’activité GPU lorsque la collecte le permet ;
- les délais jusqu’à l’affichage ;
- les images rendues par l’application et celles éventuellement générées.
Toutes les métriques ne sont pas disponibles ou aussi précises dans chaque API et chaque configuration. La documentation du projet indique par exemple des limites pour certains scénarios OpenGL, Vulkan ou avec la planification GPU accélérée matériellement. Une valeur n’a donc de sens qu’avec son nom, la version de l’outil et les conditions du test.
Lire la courbe sans chercher un chiffre magique
Je commence par repérer les pointes qui coïncident avec le symptôme. Ensuite seulement, je compare les séries.
Trois questions suffisent souvent :
- Les pointes apparaissent-elles au même endroit ?
- Leur fréquence change-t-elle après une modification ?
- Le problème est-il visible dans le jeu au même moment ?
Une capture ne prouve pas à elle seule que le processeur, la carte graphique ou le stockage est coupable. Elle indique quand le rythme se casse. Le diagnostic doit ensuite expliquer pourquoi.
Je conserve les fichiers bruts, le nom du jeu, sa version, la résolution, les réglages, le pilote et l’heure du test. Une capture sans contexte devient vite impossible à comparer.
Isoler une limite GPU
Je baisse temporairement la résolution ou l’échelle de rendu, sans toucher au reste.
Si le frametime s’améliore fortement dans la même scène, la charge graphique participe probablement au problème. Je peux alors tester les réglages qui coûtent réellement : ray tracing, ombres, distance d’affichage, qualité volumétrique ou anti-crénelage selon le jeu.
Si la baisse de résolution ne change presque rien, cela ne prouve pas que le GPU est innocent. Mais cela évite de commander immédiatement une carte plus puissante sans examiner le processeur, le moteur, le stockage ou les tâches d’arrière-plan.
Isoler une limite CPU ou moteur
Un jeu peut saturer un ou quelques fils d’exécution sans afficher 100 % sur l’ensemble du processeur. La moyenne globale masque alors le cœur occupé.
Je compare la scène avec :
- une limite d’images plus basse et stable ;
- moins de personnages, de circulation ou de simulation lorsque le jeu le permet ;
- les overlays et outils non indispensables fermés ;
- les mods désactivés sur une copie de la configuration ;
- le même test après redémarrage.
L’objectif n’est pas de désactiver définitivement chaque fonction. Il est de voir si l’irrégularité suit une charge précise.
Examiner mémoire, stockage et compilation
Les saccades peuvent accompagner le chargement d’éléments, la décompression de données, un manque de mémoire vive ou vidéo, ou la création de nouveaux shaders.
Je surveille donc :
- l’espace libre du stockage ;
- l’activité disque pendant la pointe ;
- la mémoire vive utilisée et la pagination ;
- la mémoire vidéo lorsque l’outil l’expose ;
- la répétition ou non du problème au second passage.
Une saccade qui disparaît après le premier passage n’a pas le même profil qu’une pointe qui revient toutes les dix secondes. Je n’efface pas le cache ni ne déplace le jeu tant que je n’ai pas conservé une mesure de référence.
Vérifier température, fréquence et alimentation
Une baisse de fréquence sous charge peut augmenter le temps de calcul. Je relève la température et la fréquence au moment du problème, puis je contrôle les causes simples : poussière, ventilation bloquée, profil d’alimentation, ordinateur portable sur une surface molle ou batterie très limitée.
Une température élevée ne suffit pas pour déclarer une surchauffe. Il faut la comparer aux spécifications du composant et observer si la fréquence ou la puissance chute au même instant.
Je déconseille les stress tests prolongés tant que la machine présente des arrêts, une odeur, un bruit électrique ou une température incontrôlée. Le diagnostic ne doit pas transformer un défaut en panne définitive.
Les modifications qui brouillent le diagnostic
Quelques réflexes produisent plus de bruit que de réponses :
- installer plusieurs pilotes successifs sans noter les versions ;
- appliquer un pack de réglages du registre ;
- désactiver des services Windows au hasard ;
- mélanger undervolt, overclocking et changement de pilote ;
- comparer deux zones différentes du jeu ;
- utiliser uniquement la moyenne de FPS ;
- supprimer les caches avant la première mesure ;
- conclure après un seul passage.
Je reviens toujours à une base connue avant de tester une nouvelle hypothèse.
Quand passer à GPUView
GPUView fait partie du Windows Performance Toolkit. Il analyse des traces ETW et montre l’activité CPU, GPU, les files de commandes et les événements graphiques.
C’est un outil puissant, mais beaucoup plus technique. Je le réserve aux cas où une capture plus simple confirme un problème reproductible sans en montrer la cause. Les traces peuvent devenir très volumineuses et leur interprétation demande de connaître le scénario exact.
Pour un joueur, PresentMon et une méthode rigoureuse suffisent souvent à décider si le problème suit la charge graphique, la scène, le stockage ou une tâche périodique. GPUView devient utile lorsque l’on cherche la mécanique précise sous Windows.
La fiche de test BlackFury
| Champ | Valeur à conserver |
|---|---|
| Jeu et version | |
| Windows et pilote graphique | |
| CPU, GPU, RAM, stockage | |
| Résolution et mode d’affichage | |
| Réglages principaux | |
| Limite d’images et synchronisation | |
| Scène reproduite | |
| Durée et nombre de passages | |
| Outil et version | |
| Symptôme observé | |
| Modification testée | |
| Résultat |
Cette fiche empêche de comparer deux captures qui ne mesurent pas la même chose.
Le verdict BlackFury
Une saccade n’est pas un modèle de carte graphique caché dans une courbe. C’est un événement à relier à une scène, une charge et une modification reproductible.
Le frametime permet de sortir du ressenti flou sans prétendre que l’outil pose le diagnostic à notre place. Quand une baisse de résolution, un plafond d’images ou la fermeture d’une tâche change réellement la même séquence, on obtient une piste. Quand rien ne change, on évite au moins un achat réflexe.
Avant de remplacer une pièce, je veux pouvoir répondre à trois questions : quand la saccade arrive-t-elle, quelle mesure change au même moment et quelle modification la fait disparaître de manière répétable ?
