Pourquoi 120 FPS peuvent encore sembler mauvais : temps de frame, 1 % lows et stutter expliqués
Un jeu peut afficher 120, 144 ou même 200 FPS et pourtant sembler saccadé. La raison est simple : le taux de rafraîchissement moyen indique combien d'images ont été produites au fil du temps, mais il ne dit pas si ces images sont arrivées de manière régulière. Quelques images longues peuvent créer des à-coups visibles ou un micro-stutter même lorsque le nombre moyen de FPS semble excellent.
Les FPS sont une moyenne ; le temps de frame est le rythme
Les FPS indiquent combien d'images sont terminées par seconde. Le temps de frame indique combien de temps prend une image individuelle.
La conversion approximative est simple : le temps de frame en millisecondes est environ 1000 divisé par les FPS. À 60 FPS, le budget par image est d'environ 16,7 ms. À 120 FPS, il est d'environ 8,3 ms. À 144 FPS, il est d'environ 6,9 ms.
Mais ces chiffres n'ont de sens que si la livraison des images est raisonnablement régulière. Une séquence de 7 ms, 7 ms, 7 ms, 35 ms, 7 ms, 7 ms peut toujours donner une moyenne de FPS élevée tout en produisant un à-coup perceptible.
Le Triangle de Fluidité
Trois éléments différents déterminent la sensation de rapidité d'un jeu
Un système peut être fort dans un coin et faible dans un autre. Des FPS élevés avec des temps de frame instables peuvent sembler saccadés. Un rendu stable avec une latence très élevée peut sembler fluide mais lent. Un bon réglage des performances doit identifier quel coin est réellement défaillant.
Pourquoi le nombre moyen de FPS masque les saccades
Deux sessions peuvent avoir le même nombre moyen de FPS et sembler différentes
| Session stable | Session instable | |
|---|---|---|
| FPS moyens | 120 FPS | 120 FPS |
| La plupart des temps de frame | Around 8–9 ms | Mostly 5–7 ms |
| Images lentes | Few meaningful spikes | Repeated 25–50 ms spikes |
| Expérience du joueur | Consistent motion | Hitches despite the high average |
La session instable peut compenser les images longues en rendant de nombreuses images très rapides entre les pics. La moyenne reste élevée, mais le joueur remarque les pics plutôt que la moyenne arithmétique.
Ce que les 1% lows tentent de montrer
Les métriques de FPS bas et de percentile existent parce que le nombre moyen de FPS seul ne peut pas décrire l'extrémité lente de la distribution des temps de frame.
NVIDIA FrameView rapporte le nombre moyen de FPS ainsi que les métriques 1% Low et 0.1% Low. Sa documentation décrit le 1% Low comme la moyenne des 1% d'images les plus lentes, et note que plus la valeur de FPS bas est proche de la moyenne, plus l'expérience tend à être régulière.
NVIDIA expose également des métriques basées sur les percentiles, comme le taux de rafraîchissement séparant les 1% d'images les plus lentes des 99% plus rapides. Ce sont des concepts liés, mais tous les outils de benchmark n'implémentent pas ou n'étiquettent pas les statistiques de FPS bas exactement de la même manière.
Les graphiques de temps de frame sont souvent plus utiles qu'un seul chiffre récapitulatif
Un graphique de temps de frame montre le timing des frames sur toute la capture. Une bande plate ou étroite indique généralement une cadence régulière. De grands pics isolés révèlent des à-coups. Des vagues répétitives peuvent indiquer un travail d'arrière-plan périodique, du streaming, de la synchronisation ou une autre charge de travail récurrente.
Intel PresentMon est conçu autour de ce type d'analyse. L'outil actuel d'Intel peut afficher des graphiques de performance en temps réel, des percentiles, des moyennes à fenêtre glissante et de la télémétrie GPU, et il prend en charge les applications DirectX, OpenGL et Vulkan.
NVIDIA FrameView mesure également le taux de frames et le temps de frame et peut écrire des données de capture détaillées dans des journaux pour une analyse ultérieure.
Le test de stabilité du temps de frame
Diagnostiquer si des FPS élevés masquent des saccades
Un goulot d'étranglement CPU et un goulot d'étranglement GPU ne se ressemblent pas
Un faible taux de frames ne vous dit pas quel processeur est responsable du délai. Le CPU prépare le travail de jeu et de rendu ; le GPU exécute le travail graphique. L'un ou l'autre peut devenir la limite de cadence.
La métrique GPU Busy d'Intel PresentMon est spécifiquement destinée à aider à évaluer la relation entre le temps d'exécution du GPU et le temps de frame total. Cela peut aider à distinguer les frames où le GPU est occupé pendant la majeure partie de l'intervalle de celles où une grande partie du délai se produit ailleurs.
Schémas de timing simplifiés
| Schéma de timing typique | Ce que cela peut suggérer | |
|---|---|---|
| Limité par le GPU | GPU busy time is close to the frame interval | The graphics workload is consuming most of the available frame budget |
| Contraint par le CPU / le pipeline | Frame time grows while GPU busy time remains materially lower | The delay may be before GPU execution or elsewhere in the presentation pipeline |
| Événement intermittent | Mostly stable timing with isolated large spikes | Streaming, shader compilation, background work, asset loading or another transient event may be involved |
Pourquoi un plafond de frames peut parfois sembler plus fluide que des FPS maximaux
Faire tourner un jeu au plus grand nombre de FPS possible sans plafond peut maintenir une partie du système proche de la saturation. Dans certaines charges de travail, laisser une marge peut réduire la volatilité du timing et produire une cadence plus stable.
Cela ne signifie pas que chaque jeu doit être plafonné au même nombre. Le test utile est empirique : capturez la même charge de travail sans plafond et avec un ou plusieurs plafonds raisonnables, puis comparez la stabilité du temps de frame et la latence.
Une moyenne plus basse avec une cadence de frames nettement plus régulière peut sembler meilleure qu'une moyenne plus élevée ponctuée de pics fréquents.
Causes courantes de saccades avec des FPS élevés
| Classe de cause | Ce que vous pouvez observer | Ce qu'il faut tester |
|---|---|---|
| Compilation de shaders ou de pipeline | Pics liés aux effets, lieux ou actions rencontrés pour la première fois | Répétez la même séquence et comparez les passages ultérieurs |
| Streaming d'assets / du monde | Pics lors de l'entrée dans des zones ou du chargement de nouveau contenu | Stockage, réglages de textures, comportement du streaming du monde |
| Ordonnancement CPU / travail d'arrière-plan | Pics irréguliers sans lien avec la charge GPU | Processus d'arrière-plan, overlays, enregistrement, saturation CPU |
| Saturation GPU | Temps d'exécution GPU constamment élevé | Réduisez les réglages graphiques coûteux ou testez un plafond de frames |
| Pression mémoire | Saccades croissantes sous forte utilisation VRAM/RAM | Niveau de textures, résolution, applications d'arrière-plan, comportement du working set |
| Présentation / synchronisation | Problèmes de cadence liés au rafraîchissement ou aux modes de présentation | Combinaisons V-Sync, VRR, plafond de frames et mode d'affichage |
| Régression de pilote ou de jeu | Le problème apparaît après une mise à jour spécifique | Comparez les versions ou les notes officielles sur les problèmes connus lorsque c'est possible |
La compilation des shaders est un cas particulier
Certains à-coups ne sont pas un simple problème de performance en régime stable. Une charge de travail peut tourner confortablement à haut FPS jusqu'à ce que le jeu effectue un travail coûteux qui ne se produit qu'à des moments précis.
La compilation de shaders ou de pipelines en est un exemple. Si un à-coup apparaît la première fois qu'un effet ou une zone spécifique est rencontré mais diminue ou disparaît lors des passages suivants, ce schéma est différent d'un GPU qui est continuellement trop lent.
C'est pourquoi les captures reproductibles sont importantes. Une moyenne unique sur une session entière peut mélanger un rendu stable et des événements ponctuels dans un résultat qui n'explique ni l'un ni l'autre.
Le VRR ne répare pas les mauvais temps de frame
Le taux de rafraîchissement variable peut aligner plus étroitement la synchronisation du rafraîchissement de l'écran avec la livraison variable des frames et réduire le tearing ou le judder visible dans sa plage de fonctionnement.
Mais le VRR ne transforme pas une frame de 40 ms en une frame de 8 ms. Un important blocage de rendu ou du CPU reste un important blocage. La technologie d'affichage peut améliorer la présentation ; elle ne peut pas supprimer le travail qui a retardé la frame au départ.
Pourquoi les 0,1 % les plus bas peuvent devenir bruités
Les métriques centrées sur une très petite fraction des frames sont utiles pour exposer des valeurs aberrantes sévères, mais elles deviennent aussi sensibles à la durée de capture et aux événements ponctuels.
Une courte capture contenant une transition de chargement peut produire un résultat extrême-bas très différent d'une session de jeu plus longue et reproductible. Cela ne rend pas la métrique inutile ; cela signifie que la méthodologie de test compte.
Un protocole de benchmark pratique
Mesurer un jeu sans se tromper soi-même
La fiche d'évaluation de la stabilité des temps de frame
Ce qu'il faut rechercher avant de qualifier un jeu de « fluide »
| Signal sain | Signal d'alerte | |
|---|---|---|
| Débit moyen | Meets your performance target | Average hides repeated drops below the useful range |
| Queue des frames lentes | Reasonably close to average for the workload | Large persistent gap between average and low-FPS metrics |
| Trace des temps de frame | Narrow, mostly stable band | Frequent tall spikes or recurring oscillation |
| Reproductibilité | Similar pattern across comparable runs | Result changes wildly between identical tests |
| Diagnostic temporel | CPU/GPU behavior matches the suspected constraint | Optimization is being applied without identifying the bottleneck |
Qu'est-ce qui changerait cette réponse ?
Les métriques exactes disponibles dépendent du système d'exploitation, de l'API graphique, du matériel et de l'outil de mesure. Les futurs systèmes de présentation ou pipelines de génération de frames peuvent également nécessiter des distinctions supplémentaires entre les frames rendues, générées et affichées.
Le principe fondamental est peu susceptible de changer : une moyenne de débit ne peut pas décrire entièrement la cohérence temporelle. Tant que les graphiques interactifs sont livrés sous forme de séquence de frames, la distribution et la synchronisation de ces frames comptent.
Limitations
Cet article est un cadre de diagnostic, et non l'affirmation que chaque saccade a la même cause racine. Les moteurs de jeu, les API, les systèmes d'exploitation, les pilotes et les pipelines de rendu diffèrent.
Les métriques de faible FPS doivent également être interprétées dans le cadre de la méthodologie de l'outil qui les a produites. Les comparaisons entre outils peuvent être trompeuses lorsque les définitions statistiques ou les pipelines de capture diffèrent.
Conclusion
Si un jeu affiche un FPS élevé mais reste désagréable, arrêtez de fixer la moyenne.
Mesurez les temps de frame. Inspectez la queue lente. Découvrez quand les pics se produisent. Comparez les timings CPU et GPU. Ensuite, changez une variable et répétez la même charge de travail. La fluidité ne se résume pas au nombre de frames que votre système peut produire. C'est la constance avec laquelle ces frames vous parviennent.
FAQ
FPS, temps de frame et saccades
Pourquoi 120 FPS semblent-ils encore saccadés ?
Qu'est-ce que le temps de frame ?
Que signifie 1% low FPS ?
Le 1% low est-il plus important que le FPS moyen ?
Le VRR peut-il corriger les micro-saccades ?
Dois-je limiter les FPS pour réduire les saccades ?
Glossaire
Termes clés de performance
- Temps de frame
- Le temps associé à la production ou à la présentation d'une frame individuelle, généralement exprimé en millisecondes.
- FPS moyen
- Une moyenne de débit décrivant le nombre de frames produites sur un intervalle mesuré.
- 1% Low
- Une métrique de performance des frames lentes. Le calcul exact peut différer selon l'outil ; NVIDIA FrameView décrit son 1% Low comme la moyenne des 1% de frames les plus lentes.
- Pic de temps de frame
- Une frame dont la durée est substantiellement plus longue que les frames environnantes, souvent perçue comme un à-coup ou une saccade.
- GPU Busy
- Une métrique de timing PresentMon utilisée pour comparer le temps d'exécution du GPU avec l'intervalle de frame global et aider à diagnostiquer l'équilibre CPU/GPU.
- Test de stabilité du temps de frame
- Un flux de travail Figure Rocks pour évaluer le débit moyen, la distribution des temps de frame, les métriques de frames lentes et les timings CPU/GPU dans des conditions reproductibles.
Sources primaires
Intel — PresentMonOutil officiel de surveillance des performances d'Intel avec graphiques en temps réel, percentiles, télémétrie GPU, GPU Busy et prise en charge des principales API graphiques.
NVIDIA — FrameViewOutil officiel NVIDIA pour mesurer le taux de frames, le temps de frame, la puissance et la performance par watt, à l'aide d'analyses basées sur PresentMon.
NVIDIA — Guide d'utilisation de FrameViewDocumentation officielle définissant le FPS moyen, les métriques de percentile, le 1% Low et le 0,1% Low et expliquant comment la constance est liée aux saccades.
Intel — Guide du développeur et d'optimisation des API graphiquesConseils officiels Intel couvrant les modes de présentation, les considérations d'ordonnancement CPU et l'utilisation de PresentMon pour l'analyse de la présentation des frames.
Related Articles
Frame Pacing : Pourquoi la fluidité est une question de frametime, pas de FPS
Un FPS élevé peut toujours sembler désagréable si le timing est irrégulier. Découvrez ce qu'est le frame pacing, ce qui le perturbe et l'ordre des correctifs qui rétablit une sensation de fluidité.
Saccades CPU vs Saccades GPU vs Saccades de shaders : Comment savoir ce que vous avez
Toutes les saccades ne sont pas identiques. Découvrez les trois types de saccades courants, leurs effets, et le moyen le plus rapide de les diagnostiquer avant de modifier vos paramètres.
Frame Pacing : Pourquoi 120 FPS peuvent encore sembler mauvais
La fluidité est une question de timing, pas un chiffre. Découvrez ce qu'est le frame pacing, pourquoi de mauvais frametimes semblent saccadés même à un FPS élevé, et l'ordre pratique des corrections.
Pourquoi les jeux PC saccadent lors de la compilation des shaders — et comment la livraison avancée de shaders change la donne
Les saccades de shaders se produisent lorsqu'un jeu PC doit compiler des programmes GPU au mauvais moment. Microsoft Advanced Shader Delivery déplace une grande partie de ce travail hors du PC du joueur en préparant à l'avance des shaders spécifiques au matériel et en les livrant avec le jeu.
Fluidité : la régularité des images importe plus que les FPS
La fluidité est un timing constant, pas seulement des chiffres plus élevés. Voici comment raisonner en temps de trame et éliminer la sensation de ‘micro-saccades’.
Frame Pacing : Pourquoi 60 FPS peuvent sembler pires que 50 (La régularité l'emporte)
La fluidité n'est pas seulement une question de FPS. C'est le frame pacing. Découvrez pourquoi des frametimes constants sont plus agréables qu'un FPS plus élevé mais instable et comment stabiliser le timing.
DLSS 4.5 6X : pourquoi 300 FPS ne signifie pas que le jeu rend 300 images
DLSS 4.5 peut générer jusqu'à cinq images supplémentaires pour chaque image rendue de manière traditionnelle sur les GPU de la série RTX 50 pris en charge. Ce guide explique la différence entre les FPS rendus et les FPS affichés, pourquoi les goulots d'étranglement du CPU peuvent être contournés au niveau de la couche de présentation, et pourquoi la latence doit encore être mesurée séparément.
Frame Pacing : Pourquoi 120 FPS peuvent sembler pires que 60 (La fluidité expliquée)
La fluidité est une question de régularité du timing, pas de pics de FPS. Apprenez ce qu'est le frame pacing, comment les frametimes créent des saccades et la base pratique qui corrige le ressenti.
Saccades de shaders : Pourquoi les premiers lancements saccadent et comment les réduire
Les saccades liées aux shaders se produisent lorsque de nouveaux effets sont compilés en temps réel. Apprenez à les identifier rapidement et découvrez les moyens pratiques de réduire les saccades sans réglages placebo.
Recettes de limitation d'images : Cibles stables pour les configurations VRR et non-VRR
Un bon plafonnement est plus agréable que des pics instables. Utilisez ces recettes simples de plafonnement pour stabiliser le frame pacing des écrans VRR et non-VRR.
L'utilisation de la VRAM n'est pas une exigence de VRAM : pourquoi un indicateur de mémoire plein ne raconte pas toute l'histoire
Voir 7,8 Go utilisés sur une carte graphique de 8 Go peut sembler prouver qu'un jeu a épuisé sa VRAM. Ce n'est pas si simple. Ce guide explique la capacité de la VRAM, les budgets de résidence, les ensembles de travail, la mémoire partagée et comment déterminer si la pression mémoire est réellement à l'origine des saccades.