Pourquoi un jeu peut saccader malgré une fréquence d’images élevée

Un jeu affiche plus de quatre-vingt-dix images par seconde, mais se fige brièvement quand vous tournez la caméra ou entrez dans une nouvelle zone. La moyenne des FPS n’est pas devenue inutile : elle répond à une question générale, à savoir combien d’images ont été produites pendant cet intervalle. Pour savoir si elles arrivent à un rythme régulier, il faut examiner leur durée.

Commencez par le temps de trame, puis déterminez ce qui mérite des mesures supplémentaires. Un pourcentage de goulot d’étranglement ou une seule baisse d’utilisation du GPU ne permet pas de choisir un composant à remplacer.

Une image longue peut se cacher derrière une bonne moyenne

Avec une cadence parfaitement régulière, l’intervalle entre les images en millisecondes vaut environ 1 000 ÷ FPS. Ainsi, 60 FPS correspondent à environ 16,67 ms et 120 FPS à environ 8,33 ms. C’est une conversion de temps, pas un test de performances d’un ordinateur.

Supposons qu’un enregistrement contienne 100 images : 99 durent chacune 10 ms et une dure 100 ms. Le temps total est de 99 × 10 + 100 = 1 090 ms. Le nombre d’images divisé par la durée totale donne environ 91,74 FPS. La moyenne paraît correcte, mais une attente reste beaucoup plus longue.

Figure : calcul synthétique des temps de trame et démarche de vérification, et non capture d’un benchmark de jeu.

La moyenne arithmétique des FPS instantanés de chaque image diffère aussi du nombre total d’images divisé par la durée totale. La fenêtre de mesure, l’inclusion des écrans de chargement et la définition statistique de l’outil peuvent modifier le résultat final.

Il est également utile de mesurer le temps occupé par les images lentes. Dans un enregistrement hypothétique de 60 secondes contenant six images de 100 ms, ces six images occupent à elles seules 0,6 seconde, soit 1 % de l’intervalle. Ce calcul reste synthétique, mais il conserve la trace de pauses rares qu’un percentile peut omettre.

Figure : 100 images synthétiques. L’axe horizontal représente le numéro d’image, pas des intervalles de temps égaux. L’image 50 dure 100 ms ; les 99 autres durent chacune 10 ms.

Identifier le type d’images enregistré

La page officielle de NVIDIA FrameView présente la mesure de la fréquence d’images, des temps de trame et de la puissance, avec enregistrement de journaux.[1] Ces journaux conservent les données autour d’un événement, mais un outil de capture ne prouve pas à lui seul qu’il existe un goulot d’étranglement du CPU.

Avant de comparer des rapports, vérifiez les images rendues et affichées, la génération d’images, la synchronisation verticale et les limites de FPS. Mélanger les images générées aux images rendues de base peut augmenter le chiffre sans améliorer proportionnellement la réactivité aux commandes. Des problèmes dans la chaîne d’affichage peuvent également échapper au journal de rendu : un journal régulier n’exclut donc pas toutes les saccades visibles.

Le « 1% low » aide à examiner les mauvaises performances d’image, mais son calcul peut varier selon le logiciel. Conservez avec le chiffre le nom de l’outil, sa version, la définition de la mesure et la durée d’enregistrement. Ne l’assimilez pas à l’image unique la plus lente et ne classez pas des résultats provenant d’outils différents.

CapFrameX distingue explicitement les percentiles calculés sur les images de la durée écoulée.[3] « 99 % des images respectent un seuil » ne signifie pas rigoureusement « 99 % du temps de jeu est fluide », car quelques images lentes peuvent occuper beaucoup de temps. L’explication distingue aussi les valeurs de percentile des agrégats portant sur la fraction la plus lente. Si un rapport indique seulement « 1% low » sans méthode de calcul, gardez cette limite en tête.

Quels champs du journal faut-il lire ensemble ?

Ouvrez le CSV et vérifiez d’abord ses en-têtes. La documentation de la console PresentMon définit les champs suivants ; la sortie réelle dépend de la version et des options de capture.[2]

Ces champs décrivent des intervalles différents, et les travaux CPU et GPU peuvent se chevaucher. N’additionnez pas simplement les colonnes en exigeant que leur somme égale la durée totale de l’image. MsGPUBusy n’est pas le pourcentage d’utilisation du GPU du Gestionnaire des tâches. Lisez les définitions avant de comparer deux nombres.

Si les intervalles de soumission s’allongent et que le temps actif du GPU augmente nettement, la charge graphique mérite d’être examinée. Si le travail GPU est court mais l’attente longue, une limite de FPS, l’alimentation en travail par le CPU ou l’ordonnancement peuvent intervenir. Cette observation réduit le champ de recherche ; elle ne prouve pas une puissance CPU insuffisante. Le projet décrit aussi des limites selon les API et l’ordonnancement matériel. Respectez les champs absents ou soumis à ces limites.[4]

Conserver les preuves sur un parcours court et reproductible

Choisissez un parcours reproductible en fixant résolution, réglages graphiques, mouvement de caméra et limite de FPS. Sauvegardez les réglages initiaux, lancez l’enregistrement et conservez le fichier obtenu. Indiquez dans les fichiers la version du jeu, le pilote graphique, la scène et les réglages pour permettre la comparaison.

Pour chaque pic, notez s’il apparaît à la première entrée, lors d’un mouvement brusque de caméra, au démarrage d’un programme en arrière-plan ou à chaque passage au même endroit. Examinez ensemble les mesures disponibles du CPU, du GPU, de la mémoire et du stockage. Ne remplacez pas les mesures de capteurs non enregistrées par zéro.

Effectuez d’abord trois passages et conservez chaque résultat. Si les écarts sont importants, vérifiez scène, températures, caches et tâches en arrière-plan avant d’allonger ou de multiplier les tests. Ne garder que le meilleur passage efface précisément la variation à expliquer.

Le tableau suivant est un modèle de départ. Soixante secondes et trois passages sont des exemples, sans garantie de suffire pour tous les jeux.

Comparez séparément les démarrages à froid et les scènes déjà visitées. Les saccades du premier chargement méritent leur propre enregistrement. Pour étudier une charge graphique soutenue, ne comparez pas un groupe de premiers chargements à un autre où les données sont déjà en cache.

PresentMon permet de sélectionner un processus par son nom, de fixer la durée de capture et de choisir un fichier CSV de sortie.[2] Avec une interface graphique comme en ligne de commande, confirmez le processus cible pour éviter de mêler les images du lanceur et du jeu. Aucune capture réelle de jeu n’a été réalisée ici ; les images illustrent les mesures.

Modifier une seule condition à la fois

Si vous soupçonnez la charge graphique, réduisez un paramètre de rendu bien défini puis refaites le parcours. Si vous soupçonnez une perturbation en arrière-plan, fermez un programme identifié puis recommencez. Ne changez pas simultanément pilotes, qualité graphique et limite de FPS en redémarrant le jeu : la cause d’une amélioration deviendrait impossible à isoler.

Si une qualité réduite augmente les FPS moyens mais laisse un pic au même endroit, la charge moyenne de rendu et cette pause peuvent être deux problèmes distincts. Une saccade au premier passage qui s’atténue ensuite peut impliquer le chargement de ressources ou les caches, sans que ce seul schéma en établisse la cause. Une faible utilisation du GPU peut traduire une limite de FPS, une attente du CPU ou d’autres contraintes ; elle ne signifie pas directement que la carte graphique manque de puissance.

Conservez une conclusion liée aux conditions, par exemple : « les trois passages présentent un pic à l’entrée dans la zone, et réduire les ombres ne le supprime pas », plutôt que « le PC a un goulot d’étranglement de 30 % ». Le test suivant pourra examiner cet endroit et le changement d’ombres sans repartir de suppositions.

Références

1. Page officielle NVIDIA FrameView. Établit les fonctions de fréquence d’images, de temps de trame et de journalisation. Ne prouve ni un test effectué, ni des champs de puissance identiques entre GPU, ni une installation du logiciel.

2. Documentation de PresentMon Console Application. État de la branche main consulté le 2026-09-27. Définit les champs CSV, le processus cible et la durée de capture. Les champs varient selon la version ; aucune capture locale n’est sous-entendue.

3. CapFrameX : Explanation of different performance metrics. Taxxor, 2020-05-31. Explique les percentiles et le x% low. Utilisé pour les concepts de mesure, pas comme capture de l’interface actuelle.

4. Documentation et limites du projet PresentMon. Vérifié le 2026-09-27. Les API et l’ordonnancement matériel peuvent affecter la mesure ; consignez l’environnement au lieu d’en déduire directement un goulot d’étranglement.