Vous avez réduit les paramètres graphiques mais les FPS ne se sont pas améliorés ? Vous ne corrigez probablement pas le bon goulot d'étranglement
Vous réduisez les ombres, les textures, les effets et même la résolution, mais les FPS bougent à peine. Cela ne signifie pas nécessairement que les paramètres sont défectueux. Cela signifie souvent que le paramètre que vous avez modifié ne sollicitait pas le composant qui limite actuellement les performances.
Un préréglage graphique n'est pas un levier de performance universel
Les menus graphiques regroupent de nombreuses charges de travail différentes sur un seul écran. Certains paramètres augmentent principalement la charge du GPU. D'autres augmentent la charge du CPU, le trafic mémoire, le streaming des ressources, ou les deux.
La réduction de la résolution en est un bon exemple. Elle réduit généralement le nombre de pixels que le GPU doit ombrer. Si le GPU était le composant limitant, les FPS peuvent augmenter considérablement. Si le CPU prenait déjà plus de temps pour préparer chaque trame que le GPU n'en prenait pour la rendre, la réduction du travail sur les pixels peut laisser la fréquence d'images finale presque inchangée.
Les propres recommandations d'Intel sur les goulots d'étranglement CPU/GPU rendent cette distinction explicite : réduire la résolution peut libérer des ressources GPU, tandis que des paramètres comme la distance d'affichage peuvent influencer les performances du CPU. L'effet dépend de la scène et de la charge de travail plutôt que d'une règle universelle unique « préréglage bas = plus rapide ».
Le test de réponse au goulot d'étranglement
Utilisez les changements de paramètres comme une expérience de diagnostic
Pourquoi la réduction de la résolution est un test si utile
La résolution modifie la quantité de travail sur les pixels effectuée par le GPU. Cela en fait l'un des premiers tests les plus clairs pour distinguer une situation fortement limitée par le GPU d'une situation limitée ailleurs.
Ce qu'un grand changement de résolution peut vous apprendre
| Résultat observé | Interprétation probable | Étape suivante | |
|---|---|---|---|
| Forte augmentation des FPS | FPS rises strongly | GPU rendering load was an important constraint | Tune GPU-heavy settings, resolution, upscaling or image-quality trade-offs |
| Faible augmentation des FPS | FPS barely changes | CPU, simulation, frame cap, streaming or another non-pixel workload may be limiting | Inspect CPU/GPU timing and CPU-sensitive settings |
| Réponse mitigée | Average rises but lows/stutter do not improve | GPU throughput improved but the slow-frame cause remains elsewhere | Inspect frame-time spikes, streaming, CPU scheduling and memory behavior |
| Aucune réponse à un plafond fixe | FPS stays exactly at the same ceiling | A frame cap, V-Sync limit or engine cap may be active | Identify the limiter before changing quality settings further |
Limité par le CPU ne signifie pas « le CPU est à 100 % »
Une erreur courante consiste à regarder l'utilisation totale du CPU et à conclure que le CPU ne peut pas être le goulot d'étranglement parce qu'il affiche 40 ou 60 pour cent.
Les jeux ne répartissent pas nécessairement leur travail de trame le plus important parfaitement sur tous les cœurs. Un ou quelques threads critiques peuvent déterminer quand la trame suivante peut être soumise, même si d'autres cœurs restent moins occupés.
Intel recommande une analyse de l'équilibre CPU/GPU plutôt que de se fier à un seul pourcentage d'utilisation. La métrique GPU Busy de PresentMon est spécifiquement conçue pour aider à évaluer quelle part de l'intervalle de trame le GPU exécute réellement du travail.
La carte de sensibilité des paramètres
| Classe de paramètre | Souvent sollicité | Pourquoi les FPS peuvent ou non réagir |
|---|---|---|
| Résolution / échelle de rendu | Principalement la charge de pixels du GPU | Réaction importante lorsque le GPU est limitant ; peu de réaction lorsque le CPU est limitant |
| Ray tracing / éclairage lourd | GPU | Peut fortement réduire le temps de frame GPU lorsqu'il est abaissé |
| Ombres | GPU, parfois CPU | Dépend de la distance des ombres, du nombre d'objets et de l'implémentation du moteur |
| Distance d'affichage / distance des objets | CPU + GPU | Plus d'objets peuvent augmenter la soumission, la simulation et le travail de rendu |
| Densité de foule / PNJ | Souvent CPU + GPU | L'IA, l'animation et la simulation peuvent augmenter le coût côté CPU |
| Textures | VRAM / bande passante mémoire plus que le calcul pur | Peut affecter les saccades ou la pression mémoire sans grands changements de FPS moyen |
| Effets / volumétriques | Principalement GPU | Souvent utile lorsque le temps d'exécution GPU est élevé |
| Qualité de la physique / simulation | Souvent CPU | Peut rester coûteux même à basse résolution |
| Mise à l'échelle | Charge de travail GPU et pipeline d'image | Utile principalement lorsque le coût de rendu côté GPU est important |
Une faible utilisation du GPU peut être un symptôme, pas la maladie
Si le GPU attend le CPU ou une autre partie en amont du pipeline, l'utilisation du GPU peut chuter même si le taux de rafraîchissement est bas.
Intel décrit ce schéma général comme un goulot d'étranglement : un composant limite la capacité d'un autre composant à atteindre son potentiel. Ses conseils aux développeurs montrent également des scénarios limités par le CPU dans lesquels le GPU est inactif en attendant le travail du CPU.
Cela ne signifie pas que chaque lecture de GPU à 70 pour cent prouve un goulot d'étranglement du CPU. Les limites de frames, le chargement, les menus, la gestion de l'alimentation, le comportement de la télémétrie et les transitions de scène peuvent tous affecter l'utilisation. Le timing est une preuve plus solide qu'un simple pourcentage.
Pourquoi une utilisation plus élevée du GPU n'est pas toujours l'objectif
Un GPU à 99 pour cent d'utilisation peut être parfaitement normal lorsque l'objectif est une qualité d'image ou un débit maximal. Un GPU en dessous de 99 pour cent peut aussi être parfaitement normal lorsque le taux de rafraîchissement est plafonné ou que le jeu laisse intentionnellement de la marge.
La question utile n'est pas « Comment forcer 100 % de GPU ? » mais « Qu'est-ce qui empêche la frame de se terminer plus tôt, et ai-je réellement besoin qu'elle se termine plus tôt ? »
Les limites de frames peuvent faire paraître les paramètres inefficaces
Si un jeu est plafonné à 120 FPS et atteint déjà 120 FPS, abaisser les paramètres graphiques ne peut pas faire monter le taux de rafraîchissement affiché au-dessus de ce plafond.
La marge supplémentaire peut encore compter : la charge du GPU, la consommation d'énergie, le bruit du ventilateur ou le comportement de latence peuvent changer même si le compteur de FPS reste fixe.
Avant de considérer des FPS inchangés comme preuve d'un goulot d'étranglement du CPU, vérifiez si un limiteur de jeu, un limiteur de pilote, le comportement de V-Sync ou une autre limite de présentation maintient le taux à un plafond fixe.
Pourquoi DLSS, FSR ou une échelle de rendu plus basse ne font parfois presque rien
Les technologies de mise à l'échelle réduisent la résolution d'une partie de la charge de rendu et reconstruisent l'image finale. C'est très utile lorsque le rendu des pixels est coûteux.
Mais si le CPU ou la simulation détermine déjà l'intervalle entre les frames, réduire le travail de pixels du GPU peut ne pas augmenter significativement le taux de rafraîchissement de base rendu.
C'est pourquoi un jeu peut afficher presque les mêmes FPS en résolution native et avec une résolution de rendu interne bien plus basse. Le GPU a reçu de la capacité supplémentaire, mais la frame suivante ne peut toujours pas commencer ou se terminer plus tôt car une autre dépendance est plus lente.
La génération de trames est un cas particulier
La génération de trames complique l'interprétation habituelle des FPS, car les trames générées peuvent augmenter la sortie de trames affichées sans que le CPU ait à simuler chaque trame générée.
NVIDIA documente explicitement cela comme l'une des raisons pour lesquelles la génération de trames DLSS peut augmenter le taux de trames affichées dans les scénarios limités par le CPU. Cela ne signifie pas que le goulot d'étranglement initial du CPU a disparu ; cela signifie que le pipeline de présentation peut produire des trames supplémentaires au-delà du taux natif de simulation/soumission de rendu du CPU.
Pour le diagnostic, séparez les performances de rendu de base, la sortie de trames générées et la latence d'entrée au lieu de traiter un seul compteur FPS comme l'ensemble du système.
La réactivité et les FPS ne sont pas la même mesure
Un goulot d'étranglement du CPU ou du GPU affecte également la latence différemment. La documentation NVIDIA Reflex divise le pipeline de latence en étapes comprenant l'entrée, la simulation, la soumission de rendu, le pilote, la file d'attente de rendu et le rendu GPU.
C'est utile car un changement graphique peut améliorer le temps de rendu GPU tout en laissant le temps de simulation ou de soumission CPU presque inchangé.
Ainsi, la bonne question n'est peut-être pas « Les FPS ont-ils augmenté ? » mais « La partie du pipeline qui m'intéresse est-elle devenue plus rapide ? »
Le diagnostic du mauvais goulot d'étranglement
Quand les paramètres bas et ultra offrent des performances presque identiques
Ne pas optimiser uniquement depuis le menu des paramètres
Les préréglages graphiques sont conçus pour la facilité d'utilisation, et non pour exposer l'architecture de performance du moteur.
Un préréglage « Moyen » peut modifier dix variables sans rapport à la fois. Si les performances s'améliorent, vous ne savez toujours pas quel changement a compté. Si elles ne s'améliorent pas, une option lourde pour le CPU ou le streaming peut encore dominer.
Pour le dépannage, les modifications individuelles sont plus lentes mais beaucoup plus informatives.
Un ordre de réglage pratique
Réglez le goulot d'étranglement plutôt que l'étiquette
Qu'est-ce qui changerait cette réponse ?
Le goulot d'étranglement exact peut changer d'une scène à l'autre. Un couloir intérieur peut être limité par le GPU tandis qu'une ville dense ou une bataille de stratégie devient limitée par le CPU. Le diagnostic doit donc cibler la charge de travail qui cause réellement le problème de performance.
La génération de frames, la résolution dynamique, la qualité adaptative au niveau du moteur et les futurs systèmes d'ordonnancement peuvent aussi rendre la mise à l'échelle simple des FPS moins intuitive. La méthode de base reste valable : modifiez une charge de travail, observez la réponse et identifiez l'étape qui a cessé de s'améliorer.
Limites
Cet article fournit un cadre de diagnostic, et non une correspondance universelle de chaque paramètre graphique vers un coût CPU ou GPU. L'architecture du moteur détermine la charge de travail réelle.
Les pourcentages d'utilisation seuls ne peuvent pas prouver un goulot d'étranglement. Les traces de timing, les tests reproductibles et la réponse à des modifications contrôlées des paramètres fournissent des preuves plus solides.
Conclusion
Si les modes Faible et Ultra offrent presque les mêmes FPS, ne continuez pas à baisser des paramètres au hasard.
Utilisez l'absence de mise à l'échelle comme preuve. Testez la résolution, inspectez le timing CPU/GPU, vérifiez les plafonds, puis ciblez les paramètres qui affectent la charge de travail limitante. Le réglage des performances devient beaucoup plus facile une fois que vous cessez de demander « Quel paramètre est coûteux ? » et commencez à demander « Quel composant empêche la prochaine frame de se terminer plus tôt ? »
FAQ
Paramètres graphiques, goulots d'étranglement CPU et faible utilisation du GPU
Pourquoi baisser les paramètres graphiques n'augmente-t-il pas mes FPS ?
Pourquoi 1080p et 1440p me donnent-ils presque les mêmes FPS ?
Une faible utilisation du GPU signifie-t-elle toujours un goulot d'étranglement CPU ?
Un jeu peut-il être limité par le CPU lorsque l'utilisation totale du CPU est inférieure à 100 % ?
Quels paramètres graphiques affectent le CPU ?
Pourquoi l'upscaling n'améliore-t-il pas les FPS dans certains jeux ?
Glossaire
Termes clés liés aux goulots d'étranglement
- Limité par le CPU
- Un état de performance dans lequel le travail ou la soumission côté CPU empêche la production de frames plus rapide même si le GPU dispose d'une capacité supplémentaire.
- Limité par le GPU
- Un état de performance dans lequel l'exécution du GPU consomme la portion limitante du budget de frame.
- Réponse de mise à l'échelle
- Le changement de performance produit par la modification d'une charge de travail telle que la résolution ou la qualité graphique.
- GPU Busy
- Une métrique Intel PresentMon qui aide à comparer le temps d'exécution du GPU avec le timing total des frames pour évaluer l'équilibre CPU/GPU.
- Test de réponse aux goulots d'étranglement
- Une méthode Figure Rocks qui utilise des modifications contrôlées des paramètres et des mesures de timing pour identifier quelle charge de travail limite les performances.
- Carte de sensibilité des paramètres
- Un modèle de planification Figure Rocks qui regroupe les paramètres de jeu par types de travail CPU, GPU, mémoire ou streaming qu'ils influencent couramment.
Sources principales
Intel — Localiser et résoudre les goulots d'étranglement CPU-GPUConseils officiels d'Intel sur le déséquilibre CPU/GPU, les goulots d'étranglement dépendant de la scène et la façon dont les paramètres de résolution et de distance d'affichage peuvent affecter différentes charges de travail.
Intel — PresentMonOutil officiel de surveillance des performances d'Intel avec GPU Busy, équilibre CPU/GPU, graphiques en temps réel, percentiles et télémétrie.
NVIDIA Developer — SDK ReflexDocumentation officielle NVIDIA séparant les étapes de latence et décrivant le comportement de la file de rendu et du timing CPU/GPU.
Blog technique NVIDIA — Threading CPU et performances de jeuAnalyse officielle des développeurs NVIDIA sur les charges de travail de jeu limitées par le CPU, l'ordonnancement des threads et les contraintes de performance côté CPU.
NVIDIA — Science des GPU Ada / DLSS 3Documentation technique officielle NVIDIA expliquant le comportement des jeux limités par le CPU et pourquoi la génération de frames peut augmenter les FPS affichés sans exiger que le CPU rende chaque frame générée.
Related Articles
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.
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.
Checklist routeur pour le gaming : les paramètres qui comptent vraiment
La plupart des optimisations de routeur n'aident pas. Ces paramètres, oui : gestion des files d'attente sous charge, comportement Wi-Fi stable et éviter les fonctionnalités qui ajoutent de la latence ou de l'instabilité.
DirectStorage 1.4 ne fait pas décompresser vos jeux par votre SSD : ce que font réellement Zstd et la décompression GPU
DirectStorage 1.4 ajoute la compression Zstandard, la décompression GPU et une nouvelle Game Asset Conditioning Library, mais le SSD lui-même ne reste qu'une partie du pipeline de chargement. Ce guide explique ce que le SSD, DirectStorage, le CPU, le GPU et le moteur de jeu font réellement chacun.
NVIDIA Reflex Basics: When It Helps (And When It Does Nothing)
Reflex reduces render queue delay when the game is GPU-bound and stable. Learn the practical conditions where it helps and the traps that make it pointless.
Checklist routeur v2 : Les 12 paramètres qui empêchent les pics de latence
La plupart des pics de latence proviennent de la charge et de l'instabilité, et non d'un ‘mauvais ping’. Utilisez cette checklist pour routeur pour stabiliser la latence sous charge avant d'acheter du nouveau matériel.
Matrice de décision HDR vs SDR : quand le HDR aide et quand le SDR l'emporte
Le HDR n'est pas toujours meilleur. Utilisez cette matrice de décision simple pour choisir le HDR ou le SDR par jeu en fonction de la lisibilité, de la stabilité et du comportement réel de votre écran.
La compression de textures neuronale RTX n'est pas de la mise à l'échelle : comment l'IA peut échanger de la mémoire de textures contre de la puissance de calcul GPU
NVIDIA RTX Neural Texture Compression change la façon dont les matériaux de jeu peuvent être stockés. Au lieu de conserver chaque canal de texture uniquement sous forme de texels conventionnels, un matériau peut être compressé en données latentes compactes et un petit décodeur neuronal, puis reconstruit par le GPU lorsque nécessaire.
Stockage et streaming : réduire les temps de chargement sans créer de saccades
Un stockage rapide n'est utile que si le comportement de streaming est stable. Ce guide explique comment les E/S affectent les saccades et ce qu'il faut changer en premier.