Calculateur de goulot d’étranglement CPU/GPU

Le temps d’image est un bon point de départ

Le nombre d’images par seconde est l’inverse du temps d’image. Lorsque le temps est exprimé en millisecondes :

plafond de fréquence d’images = 1000 / temps d’image en ms

Dans ce modèle simplifié, l’étape mesurée la plus lente fixe le plafond de l’ensemble du pipeline :

plafond estimé = 1000 / max(temps d’image CPU, temps d’image GPU)

Il s’agit d’une estimation de diagnostic, et non de la promesse que le jeu affichera des images exactement à cette fréquence. Une limite de fréquence d’images, la synchronisation, les files d’attente, le travail du moteur, le chargement, l’ordonnancement du système d’exploitation et la présentation à l’écran peuvent tous influer sur les FPS observés. Dans ses recommandations de profilage DirectX, Microsoft définit séparément le temps CPU et le temps GPU par image, car chacun peut dépasser le budget disponible pour une image.

La conversion 1000 / ms donne un plafond pour l’étape mesurée. Par exemple, un temps CPU de 12 ms correspond à environ 83,33 FPS, tandis qu’un temps GPU de 7 ms correspond à environ 142,86 FPS. Dans cette capture, le côté CPU est le plus lent et le plafond simplifié est d’environ 83,33 FPS.

Pourquoi la tolérance est importante

Des temps d’image proches ne doivent pas conduire à une conclusion excessivement catégorique. Ce calculateur compare l’écart absolu au temps d’image du côté le plus lent :

écart relatif = |CPU ms - GPU ms| / max(CPU ms, GPU ms) × 100

Si cet écart reste dans la tolérance choisie, le résultat est équilibré ou indéterminé pour cette capture. S’il dépasse la tolérance, le côté dont le temps d’image est le plus long constitue la limitation actuelle.

Ce pourcentage décrit l’écart entre deux mesures de temps au sein d’une charge de travail donnée. Il ne correspond ni au pourcentage de ressources CPU ou GPU gaspillées, ni au gain de performances prévisible après un changement de matériel.

Rendez la capture reproductible

Pour que la comparaison soit utile, la charge de travail doit rester stable. Conservez les mêmes :

• version du jeu et du moteur ;
• sauvegarde, rediffusion, séquence de benchmark ou parcours de déplacement fixe ;
• définition, échelle de rendu, préréglage de qualité et API graphique ;
• limite de fréquence d’images, état de VSync et état de la définition dynamique ;
• réglages du pilote, mode d’alimentation et charge en arrière-plan ;
• durée de préchauffage et durée de capture.

Exécutez le test plusieurs fois et comparez des statistiques représentatives au lieu de vous fier à un seul échantillon court. Les recommandations d’AMD sur les performances CPU préconisent de fixer des variables telles que la scène de test et la graine aléatoire. Dans son guide consacré à Unreal Engine, AMD suggère également de modifier la définition à des fins de diagnostic : si une définition de rendu nettement supérieure change à peine les performances, cela constitue un indice qui mérite d’être examiné pour rechercher une limitation côté CPU dans cette charge de travail. Il ne s’agit toutefois que d’un indice, pas d’un verdict universel.

Pourquoi le taux d’utilisation ne constitue pas une preuve

Le taux d’utilisation peut étayer un diagnostic, mais ne suffit pas à l’établir. L’utilisation totale du CPU peut sembler modérée alors qu’un thread principal ou de rendu est saturé. Une faible utilisation du GPU peut provenir d’une limite de fréquence d’images, d’une attente du CPU, de la synchronisation ou d’une quantité insuffisante de travail soumis. Une utilisation élevée du GPU indique que le composant était occupé ; elle ne permet ni d’identifier précisément la passe coûteuse, ni de prévoir le résultat d’une mise à niveau.

Les outils de mesure du temps apportent davantage de contexte. Intel PresentMon enregistre la télémétrie des images et du GPU, NVIDIA Nsight affiche les durées d’image côté CPU et GPU ainsi que les plages de charge de travail du GPU, et AMD Radeon GPU Profiler représente les temps dans les files d’attente et les périodes d’inactivité du GPU. Même les seuils des profileurs restent des heuristiques : pour classer une charge comme limitée par le CPU, Radeon GPU Profiler utilise un seuil d’inactivité du GPU réglable, et non une règle absolue valable pour tous les moteurs.

Ce que le « 1 % low » permet ou non de savoir

Le « 1 % low » résume la partie lente de la distribution des temps d’image. Il aide donc à repérer une irrégularité d’affichage qu’une moyenne peut masquer. En revanche, il ne permet pas de déterminer si ces images lentes sont dues au CPU, au GPU, au chargement progressif des ressources, à la compilation des shaders, à une pression sur la mémoire ou à un autre blocage.

Les définitions varient également. Certains rapports calculent une fréquence à partir du 99e centile du temps d’image (1000 / temps d’image p99), tandis que d’autres font la moyenne des 1 % d’échantillons FPS les plus faibles. NVIDIA Nsight Systems définit la durée d’image au 99e centile comme la valeur que seulement 1 % des images dépassent. Lorsque vous comparez des résultats, notez l’outil et la définition employés, et ne remplacez pas les temps CPU et GPU correspondants par une valeur de « 1 % low ».

Pourquoi les pourcentages universels de goulot d’étranglement sont trompeurs

Un ordinateur ne possède pas un rapport de goulot d’étranglement CPU/GPU permanent. Le travail limitant peut changer selon le jeu, la scène, la définition, les réglages, la version du moteur, le pilote, la limite de fréquence d’images et la fréquence visée. Une scène urbaine animée peut solliciter davantage la simulation et l’envoi des appels de dessin, tandis qu’une autre scène, avec une échelle de rendu supérieure, peut demander plus de temps au GPU.

Les calculateurs fondés sur le nom des composants ne peuvent pas observer ces conditions. Un résultat tel que « 23 % de goulot d’étranglement », sans mesure de temps effectuée dans la même scène, n’a pas de signification technique stable. Utilisez ce calculateur pour décrire la capture que vous avez réellement réalisée, répétez le test avec la charge de travail qui vous intéresse et servez-vous d’un profileur de chronologie pour identifier précisément le travail responsable.

Références techniques officielles

• Microsoft : profilage des applications DirectX
• Intel : suivi des performances avec PresentMon
• NVIDIA : état des images dans Nsight Systems
• NVIDIA : GPU Trace dans Nsight Graphics
• AMD GPUOpen : présentation de Radeon GPU Profiler
• AMD GPUOpen : guide des performances d’Unreal Engine
• AMD GPUOpen : guide des performances des CPU Ryzen