Pourquoi les CPU créent un goulot d’étranglement pour les GPU en 1080p (et pas en 4K)

Idée centrale : qui impose le rythme par image

Une image rendue est une chaîne de traitement. Le CPU réalise une série de travaux pour préparer une image : simulation, visibilité,
animation, construction des buffers de commandes, communication avec le pilote, planification du travail et gestion du bruit OS. Le GPU fait les calculs lourds
pour exécuter l’image : traitement des sommets/meshes, rastérisation, shading, requêtes ray, post-traitement et écriture des pixels.

Le framerate est fixé par le côté le plus lent. Si le CPU met 8 ms pour produire le travail de la frame suivante et que le GPU met 5 ms pour la rendre,
vous n’obtenez pas 200 FPS. Vous obtenez 125 FPS (et le GPU est en attente que le CPU lui fournisse le lot suivant). Si le GPU met 12 ms
et que le CPU met 6 ms, vous obtenez 83 FPS et le CPU attend.

C’est pourquoi « l’utilisation du GPU » est un piège quand on la regarde comme un tachymètre. Un GPU peut être sous-utilisé parce que :
(1) il attend le CPU, (2) il attend la mémoire ou des transferts PCIe, (3) le jeu est limité ou vsyncé, ou (4) le pilote sérialise le travail d’une manière que votre
outil de monitoring n’expose pas proprement. L’utilisation est une preuve. Ce n’est pas un diagnostic.

Pourquoi le 1080p est « territoire CPU » et la 4K « territoire GPU »

La résolution change plus le travail GPU que le travail CPU

Passer de 1080p (1920×1080) à 4K (3840×2160) quadruple le nombre de pixels. Pas « un peu plus ». Quatre fois plus de pixels.
Cela amplifie le travail GPU qui évolue avec le nombre de pixels : shading des fragments, passes de post-traitement, certains modes d’AA, la bande passante pour écrire les
render targets, et le coût des effets haute qualité qui s’exécutent par pixel.

Ce qui n’évolue pas beaucoup avec la résolution ? Une grande partie du travail CPU : tick de logique de jeu, step physique, décisions d’IA, évaluation des graphes d’animation,
décisions de culling, traversée du scene graph et la simple surcharge de soumission des draw calls et des bindings de ressources. Ces coûts sont liés à
combien d’objets existent et à la façon dont le moteur organise le travail, pas au nombre de pixels affichés.

En 1080p, le GPU termine vite, puis attend

Avec moins de pixels, le GPU termine souvent sa portion de la frame plus rapidement, surtout sur des cartes haut de gamme. Si le CPU n’arrive pas à produire
du nouveau travail assez vite — parce qu’un cœur est saturé par le thread de jeu, que le thread du pilote est occupé, ou que des tâches d’arrière-plan volent du temps — le GPU
manque de commandes et se bloque.

C’est le « goulot d’étranglement CPU ». Ce n’est pas mystique. C’est la famine. Vous avez acheté une cuisine très rapide (GPU), mais le serveur (CPU + pilote)
n’apporte les ingrédients qu’une assiette à la fois.

En 4K, le GPU a enfin de quoi mastiquer

En 4K, le temps GPU par image augmente considérablement. Beaucoup de scènes deviennent GPU-bound parce que le shading et la bande passante dominent. Le CPU fait toujours
la même orchestration, mais maintenant le GPU est l’étape la plus lente. L’utilisation GPU grimpe vers 95–99 %, et le framerate s’aligne sur
ce que vous attendez des benchmarks GPU.

Le piège du FPS compétitif

Les goulots d’étranglement CPU les plus dramatiques apparaissent en configuration compétitive : basse résolution, graphismes bas, FPS illimité, taux de rafraîchissement élevé.
Ces configurations réduisent intentionnellement la charge GPU pour maximiser le framerate et diminuer la latence — elles vous poussent donc directement vers les limites CPU.

Blague n°1 : Acheter un GPU flagship pour du 1080p avec les réglages bas et attendre des miracles, c’est comme installer un moteur à réaction sur un caddie — techniquement impressionnant, opérationnellement déroutant.

Ce que le CPU fait réellement dans un jeu moderne

Si vous voulez comprendre pourquoi le CPU peut créer un goulot d’étranglement en 1080p, arrêtez de penser au « CPU » comme une seule chose. Dans de vrais moteurs, la charge CPU
est répartie sur plusieurs threads avec un parallélisme inégal et des points de synchronisation pénibles.

1) Le « main/game thread » et les points d’étranglement sériels

Beaucoup de moteurs ont encore un thread principal qui coordonne l’étape de simulation : input, logique de gameplay, scripting, IA haut niveau et mises à jour de scène.
Même dans les moteurs avec de forts job systems, certaines contraintes d’ordre sont intrinsèquement sérielles : on ne peut pas résoudre certaines interactions physiques
avant d’avoir avancé le monde ; on ne peut pas faire spawn d’objets avant l’exécution de la logique ; on ne peut pas finaliser la visibilité avant la mise à jour des transforms.

Quand on dit « un cœur est saturé », c’est généralement cela qu’on veut dire. Un CPU 16 cœurs n’aide pas si le thread limitant ne peut pas être découpé.
Des workers parallèles peuvent rester à 20 % d’inactivité pendant que le thread principal brûle à 100 % et que le GPU attend poliment.

2) Préparation du rendu : culling, tri et génération de commandes

Le rendu moderne n’est pas « envoyer des triangles ». C’est : déterminer les objets visibles, choisir les LODs, construire les listes de rendu, trier pour réduire les changements d’état,
binder les ressources et construire les command buffers. C’est du travail CPU.

Les moteurs qui reposent fortement sur beaucoup de petits draw calls peuvent écraser le CPU en 1080p parce que la soumission des draw calls et la validation d’état sont
coûteuses, surtout dans les anciens APIs graphics ou lorsque le pilote sérialise.

3) Surcharge du pilote et modèle d’API

Le pilote fait partie de votre coût CPU. Quand vous soumettez du travail, le pilote le valide, le traduit et peut le regrouper ou le réordonner.
Une partie peut être parallélisée ; une autre est obstinément mono-thread, surtout dans les chemins legacy.

DirectX 11 est réputé pour une surcharge de draw calls plus élevée dans de nombreux workloads à cause de la gestion d’état et de la façon dont les pilotes doivent opérer.
DirectX 12 et Vulkan transfèrent plus de responsabilités au moteur, ce qui peut réduire la surcharge si le moteur les utilise correctement.
« Utiliser DX12 » n’est pas une victoire gratuite. C’est une chance de ne pas perdre.

4) Streaming d’actifs et gestion mémoire

Le streaming de textures et de géométrie est aussi un problème CPU : décompression, ordonnancement IO, décisions de residency et gestion des heaps.
Si vous voyez des saccades en tournant rapidement, cela peut être du temps CPU passé à réagir à la pression de streaming, pas seulement un « disque lent ».
(Oui, le stockage compte. Mais c’est généralement le CPU qui coordonne le bazar.)

5) L’OS : DPCs, interruptions, services en arrière-plan

Le CPU gère aussi les interruptions, la planification kernel, les stacks audio, l’anti-cheat, les overlays, les logiciels de capture et tout ce qui a décidé de se réveiller au mauvais moment.
Quelques centaines de microsecondes de jitter sur le mauvais cœur deviennent une frame manquée à 240 Hz.

Ce qui change avec la résolution (et ce qui ne change pas)

Le coût GPU évolue avec les pixels, mais pas toujours linéairement

Quadrupler le nombre de pixels ne quadruple pas toujours le temps GPU parce que les workloads GPU incluent des composants qui ne sont pas liés aux pixels :
le traitement de la géométrie, des effets compute avec un travail fixe par objet, et des bulles imposées par le CPU dans la pipeline.

Mais pour la plupart des titres modernes, la 4K vous pousse dans un régime où le shading des pixels, le post-traitement et la bande passante dominent. C’est à ce moment-là
que le GPU devient le limitateur et que les lacunes du CPU sont masquées.

Le travail CPU est lié à la « complexité du monde », pas à la résolution

Le CPU ne se soucie pas que vous rendiez la même scène en 1080p ou en 4K : il doit toujours décider ce qui est visible, simuler les mêmes PNJ et
construire le même nombre de draw calls. Si vous gardez les mêmes paramètres graphiques et la même scène, la charge CPU reste souvent proche de plate.

Pourquoi baisser les réglages peut vous rendre « plus lié au CPU »

Baisser les réglages réduit le temps GPU. Cela augmente les FPS jusqu’à ce que vous atteigniez le mur CPU. Ensuite, les FPS cessent d’évoluer et on a l’impression que votre upgrade GPU
n’a servi à rien. Il a fait quelque chose — il a supprimé les limites GPU, exposant la limite CPU qui existait déjà.

Le temps par frame est la seule métrique qui ne ment pas

Le FPS est un résumé. Le temps par frame est l’autopsie. Si vous vous souciez des goulots d’étranglement, vous avez besoin du temps CPU par frame vs temps GPU par frame.
Le côté limitant est celui avec le plus grand temps par image. Tout le reste, c’est du ressenti.

Une citation opérationnelle à garder sur un post-it :
L’espoir n’est pas une stratégie. — General Gordon R. Sullivan

Faits et contexte historique qui expliquent le bazar d’aujourd’hui

• Fait 1 : Le meme « goulot d’étranglement CPU » s’est amplifié quand le 1080p à haute fréquence pour l’esport est devenu courant ; le 240 Hz rend le jitter CPU visible.
• Fait 2 : Le modèle immediate context de DirectX 11 force souvent plus de travail pilote sur le CPU ; il a été conçu à une époque avec d’autres attentes de threading.
• Fait 3 : Les moteurs console ont poussé des job systems agressifs parce que le hardware fixe l’exigeait ; les ports PC héritent parfois bien, parfois mal de ces patterns.
• Fait 4 : Les « limites de draw calls » étaient autrefois dans les quelques milliers sur d’anciens APIs et pilotes ; aujourd’hui les moteurs peuvent en pousser bien plus, mais seulement avec du batching et du threading soignés.
• Fait 5 : L’essor du post-processing lourd en shaders (TAA, SSR, variantes d’AO) a rendu la 4K disproportionnellement coûteuse, déplaçant les goulots vers le GPU.
• Fait 6 : La bande passante PCIe limite rarement le rendu en steady-state, mais les pics d’upload (streaming, compilation de shaders, création PSO runtime) peuvent provoquer des saccades qui ressemblent à un goulot CPU.
• Fait 7 : Le SMT/Hyper-Threading aide le débit, mais beaucoup de jeux sont limités par un ou deux threads « chauds » où le SMT ne double pas les performances.
• Fait 8 : Les options de « threaded optimization » du pilote existent parce que la surcharge CPU du pilote est réelle ; c’est aussi fragile car cela change le scheduling et le locking.

Playbook de diagnostic rapide

Première étape : déterminer si vous êtes CPU-bound ou GPU-bound en 2 minutes

1. Changez uniquement la résolution (1080p → 1440p → 4K) avec les mêmes réglages.
   
   Si les FPS changent peu quand la résolution augmente, vous êtes CPU-bound. Si les FPS chutent notablement avec la résolution, vous êtes GPU-bound.
2. Regardez le temps par frame CPU vs GPU (pas seulement l’utilisation).
   
   Si le temps CPU par frame > temps GPU par frame, CPU-bound. Si le temps GPU par frame > temps CPU par frame, GPU-bound.
3. Vérifiez les caps et la synchronisation.
   
   Si vous êtes bloqué à 60/120/144/165/240, vous atteignez peut-être un limiteur (vsync, cap de frame, plafond VRR, limiteur pilote).

Deuxième étape : identifier le limiteur CPU spécifique

1. Un seul cœur est saturé ? Probablement le thread principal, le thread pilote, ou un sous-système lourd (IA/physique).
2. Temps DPC/ISR élevé ? Probablement latence pilote/interruption : réseau, audio, stockage, USB ou périphériques de capture.
3. Saccades pendant la traversée ? Souvent compilation de shaders, création de PSO ou coordination de streaming d’actifs.

Troisième étape : faites le changement le moins cher avec le ROI attendu le plus élevé

• Activez un cap de frame raisonnable en dessous de votre rafraîchissement pour stabiliser le pacing.
• Activez l’upscaler recommandé par le moteur en 4K plutôt que de forcer le natif.
• Si votre objectif est le 1080p à haut FPS, priorisez la fréquence/IPC du CPU et la latence mémoire, pas « plus de GPU ».

Tâches pratiques : commandes, sorties, ce qu’elles signifient, et la décision

Ce sont des outils de terrain. Pas parfaits. Mais constants, scriptables et qui donnent des indices tangibles. L’hôte s’appelle « server » parce que je suis SRE
et les habitudes ont la vie dure.

Task 1: Verify CPU model, boost behavior, and core layout

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|MHz'
Model name:                           AMD Ryzen 7 7800X3D 8-Core Processor
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
CPU MHz:                              4482.000

Signification de la sortie : Confirme le nombre de cœurs/threads et l’instantané de fréquence actuel. Si vous voyez des MHz faibles en charge, vous êtes peut-être limité par l’alimentation/la thermique.

Décision : Si les clocks ne boostent pas, corrigez le refroidissement/le plan d’alimentation/les limites BIOS avant de chasser des « goulots ».

Task 2: Check CPU frequency governor (Linux) or policy drift

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil

Signification de la sortie : « schedutil » est généralement correct ; « powersave » peut nuire à la stabilité à haut FPS.

Décision : Pour des benchmarks, utilisez temporairement « performance » pour supprimer la variance induite par le governor.

Task 3: See per-core pressure (find the pegged thread)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (server) 	01/21/2026 	_x86_64_	(16 CPU)

01:10:01 PM  CPU   %usr  %nice  %sys %iowait  %irq  %soft  %steal  %idle
01:10:02 PM  all  22.10   0.00  3.10    0.10  0.00   0.30    0.00  74.40
01:10:02 PM    6  88.00   0.00  4.00    0.00  0.00   0.00    0.00   8.00
01:10:02 PM    7  12.00   0.00  2.00    0.00  0.00   0.00    0.00  86.00

Signification de la sortie : Un cœur CPU (CPU 6) est presque saturé tandis que les autres ne le sont pas. C’est un comportement classique de « thread principal » ou de sérialisation pilote.

Décision : Optimisez pour la performance mono-thread : upgrade CPU, tuning mémoire, ou paramètres moteur qui réduisent le travail du thread principal (distance de vue, densité de foule).

Task 4: Confirm GPU is present and which driver stack you’re on

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvidia|amd'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)

Signification de la sortie : Vous ne pouvez pas tuner ce que l’OS ne voit pas. Cela aide aussi à attraper un « mauvais slot » et des problèmes de câblage PCIe bizarres.

Décision : Si le GPU n’est pas correctement énuméré, stoppez. Corrigez le hardware/BIOS/config PCIe avant l’analyse de perf.

Task 5: Check PCIe link width and speed (common silent limiter)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16

Signification de la sortie : Vous voulez que LnkSta corresponde à LnkCap en vitesse et en largeur. x8 ou Gen3 peut compter dans des cas limites, surtout avec du heavy streaming.

Décision : Si vous voyez x4 ou Gen1/Gen2, réinsérez le GPU, vérifiez le mode PCIe du BIOS et vérifiez que le bon slot est utilisé.

Task 6: Watch GPU utilization and clocks (sanity, not diagnosis)

cr0x@server:~$ nvidia-smi --query-gpu=utilization.gpu,clocks.gr,clocks.mem,pstate,power.draw --format=csv -l 1
utilization.gpu [%], clocks.gr [MHz], clocks.mem [MHz], pstate, power.draw [W]
62 %, 2730 MHz, 10501 MHz, P0, 220.45 W
58 %, 2715 MHz, 10501 MHz, P0, 214.10 W

Signification de la sortie : Une utilisation modérée avec des clocks élevées peut signifier CPU-bound, cap, ou workloads inégaux. P0 indique qu’il n’est pas en low-power state.

Décision : Si les clocks sont basses (P2/P5) en charge, corrigez la gestion d’alimentation ou les réglages du pilote avant de poursuivre le diagnostic CPU.

Task 7: Check CPU scheduling latency sources (interrupt storms)

cr0x@server:~$ cat /proc/interrupts | head
           CPU0       CPU1       CPU2       CPU3
  0:         52          0          0          0   IO-APIC   2-edge      timer
  1:          0          0          0          0   IO-APIC   1-edge      i8042
 24:    1200345          0          0          0   PCI-MSI 65536-edge      eth0
 27:     450221          0          0          0   PCI-MSI 327680-edge      nvme0q0

Signification de la sortie : Si un CPU gère un nombre ridicule d’interruptions (réseau, NVMe), il peut voler du temps au thread chaud du jeu.

Décision : Envisagez l’équilibrage IRQ, désactivez les périphériques/ pilotes qui posent problème, ou déplacez des workloads hors du cœur que le jeu utilise (selon plateforme).

Task 8: Identify whether you’re stalling on IO (streaming pressure)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
         21.14    0.00    3.05    0.80    0.00   74.99

Device            r/s     w/s   rkB/s   wkB/s  %util  await
nvme0n1         120.0    15.0  8200.0  1200.0   35.0   2.10

Signification de la sortie : Un %util modéré et un await faible suggèrent que le stockage n’est pas le facteur limitant. Des pics d’await élevés coïncident avec des saccades pendant la traversée.

Décision : Si l’await est élevé, investiguez les mises à jour en arrière-plan, l’antivirus ou un SSD saturé ; sinon, concentrez-vous sur le temps par frame CPU/GPU.

Task 9: Catch thermal throttling (the “invisible handbrake”)

cr0x@server:~$ sensors | egrep -i 'Tctl|Package|Core|temp|fan'
Tctl:         +86.5°C
Core 0:       +84.0°C
Core 1:       +83.5°C
fan1:        1850 RPM

Signification de la sortie : Des températures élevées soutenues peuvent réduire les clocks de boost, surtout avec de petits refroidisseurs ou une mauvaise pâte thermique.

Décision : Si les températures sont proches des points de throttle, corrigez le refroidissement d’abord. Tuner une machine qui bride thermiquement, c’est du déni organisé.

Task 10: Check memory speed and whether you’re running a “safe” profile

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Speed:|Configured Memory Speed'
Configured Memory Speed: 4800 MT/s
Speed: 6000 MT/s

Signification de la sortie : Vitesse RAM nominale vs vitesse configurée. Les jeux CPU-bound en 1080p peuvent être sensibles à la latence et à la bande passante mémoire.

Décision : Si la vitesse configurée est basse, activez le bon profil XMP/EXPO et validez la stabilité.

Task 11: Find background processes that steal frametime at high FPS

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
 4123 game.exe        62.5  8.1
 2311 obs             12.2  3.4
 1990 chrome           6.8  2.1

Signification de la sortie : Les processus de capture/overlay et les navigateurs peuvent introduire du jitter, surtout s’ils déclenchent une contention GPU/CPU ou se réveillent fréquemment.

Décision : Si des processus non liés au jeu consomment du CPU significatif, fermez-les ou déplacez la capture sur une machine séparée si vous tenez au 240 Hz stable.

Task 12: Check if you’re hitting a frame cap (you’d be amazed)

cr0x@server:~$ grep -R "MaxFPS" -n ~/.config/game/config.ini | head
42:MaxFPS=144

Signification de la sortie : Un cap imposé par config va mimer un goulot CPU : utilisation GPU faible, plafond FPS stable.

Décision : Supprimez ou ajustez le cap pour les tests. Puis réappliquez un cap volontaire pour le pacing une fois les limites comprises.

Task 13: Measure CPU-side stalls and context switches during gameplay sampling

cr0x@server:~$ pidof game.exe
4123

cr0x@server:~$ sudo pidstat -p 4123 -w -u 1 5
Linux 6.8.0 (server) 	01/21/2026 	_x86_64_	(16 CPU)

01:15:11 PM   UID       PID    %usr %system  %CPU   cswch/s nvcswch/s  Command
01:15:12 PM  1000      4123   58.00    4.00 62.00   1200.00    35.00  game.exe
01:15:13 PM  1000      4123   57.00    4.00 61.00   1400.00    40.00  game.exe

Signification de la sortie : Des context switches élevés peuvent impliquer de la contention, de l’overhead de synchronisation ou du bruit de scheduling OS.

Décision : Si les context switches augmentent avec les saccades, réduisez les overlays, vérifiez les problèmes de pilote et privilégiez le plein écran exclusif quand c’est possible.

Task 14: Verify hugepages/THP behavior (can affect frametime variance)

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Signification de la sortie : Les réglages THP peuvent influencer le comportement mémoire ; certaines charges voient une variance de latence.

Décision : Si vous chassez la micro-saccade sur Linux, testez les modes THP en A/B. Changez une chose à la fois et consignez les deltas de frametime.

Blague n°2 : Les graphes de frametime sont comme des analyses de sang — personne n’en veut, tout le monde en a besoin, et les résultats accusent toujours quelque chose auquel vous ne pensiez pas.

Trois mini-histoires d’entreprise du terrain

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Un studio avait une config PC qui « semblait correcte » en 4K dans le labo. L’utilisation GPU était élevée, le temps par frame lisse. Ils ont expédié un preset compétitif
ciblant le 1080p/240 Hz. Quelques jours plus tard, les tickets support ont afflué : « GPU seulement 60 % utilisé », « CPU à 40 % », « saccades dans les combats », « mon GPU cher est cassé ».

L’hypothèse était simple et fausse : « Si l’utilisation CPU globale est faible, ce ne peut pas être le goulot ». Ils lisaient la moyenne sur 16 cœurs et déclaraient victoire.
Le thread principal saturait un seul cœur, et le thread de soumission de rendu était périodiquement bloqué sur un lock dans le chemin pilote quand beaucoup de petits objets entraient dans la vue.

Leur plan de test interne n’incluait pas « réglages bas + FPS illimité + rafraîchissement élevé » parce que la culture du labo était cinématographique : on testait en 4K, réglages max,
on admirait l’éclairage, on livrait. Les clients réels essayaient d’optimiser chaque milliseconde de latence et exposaient le pire comportement CPU.

La correction n’était pas un patch magique. Ils ont réduit le nombre de draw calls en fusionnant certains props, amélioré l’instancing, et déplacé une partie du travail de visibilité
dans un job system pour réduire les pics du thread principal. Ils ont aussi modifié leur télémétrie pour capturer le temps par thread et la durée de soumission pilote.
Les tickets support ont chuté parce que le logiciel a changé et parce que leur explication correspondait enfin à la réalité.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une grande entreprise exécutait un logiciel de visualisation interne sur des postes avec de gros GPU. Une équipe a « optimisé » le temps de démarrage en mettant en cache agressivement
les shaders compilés et en préchargeant de gros assets au login. Le démarrage s’est accéléré — sur leurs machines de test.

Puis la contre-performance est arrivée : en 1080p, des utilisateurs se sont plaints de hitchs aléatoires lors des mouvements de caméra qui n’existaient pas avant. Les graphes GPU semblaient inactifs.
Le CPU faisait des pics en rafales, et les hitchs coïncidaient avec des churns de residency d’actifs. Leur caching avait augmenté l’empreinte mémoire ; l’OS a commencé à évincer
et paginer plus agressivement sur les machines avec moins de RAM. Chaque mouvement de caméra déclenchait une cascade de travail de streaming « utile » qui volait du CPU au thread de préparation.

L’optimisation était correcte isolément et mauvaise en contexte production. Ils ont traité la mémoire comme un pool infini et ont ignoré que beaucoup d’utilisateurs
avaient d’autres apps lourdes ouvertes simultanément. Réalité classique en entreprise : quelqu’un a toujours vingt onglets de navigateur ouverts, et oui, ils sont tous « travail ».

La solution a été ennuyeuse mais efficace : limiter la taille du cache, prioriser les assets par réutilisation prédite, et ajouter du backpressure pour que le streaming cède
quand le budget frame est serré. Ils ont aussi ajouté un « mode faible latence » qui réduit l’agressivité du streaming en arrière-plan quand l’utilisateur demande un haut FPS.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre équipe maintenait une flotte de stations pour simulation et démos de type jeu lors de salons. Ils avaient une règle : chaque mise à jour de pilote
devait passer par un pool canari avec une suite de benchmarks reproductible à trois résolutions (1080p compétitif, 1440p équilibré, 4K showcase).

C’était profondément peu glamour. Les gens se plaignaient que ça freinait « l’innovation ». Mais l’équipe gardait des logs : utilisation CPU par cœur, clocks GPU, état du lien PCIe,
percentiles de frametime, et un court capture des interruptions système. Même scripts, mêmes machines, même procédure. Pas d’héroïsme.

Un mois, une mise à jour pilote améliorait légèrement la perf 4K mais introduisait des pics sporadiques côté CPU en 1080p dans un chemin applicatif. La suite canari
l’a détecté immédiatement : le 99e percentile du temps par frame a bondi, l’utilisation GPU a chuté, et les context switches du thread de soumission ont doublé. Ils ont
bloqué la mise à jour et envoyé un rapport fournisseur avec des preuves ne reposant pas sur des impressions.

La semaine du salon s’est déroulée sans embarras. La « pratique ennuyeuse » n’avait pas pour but d’augmenter les perf ; elle visait à prévenir des régressions qui n’apparaissent que dans les régimes CPU-bound.
Les utilisateurs n’ont jamais su ce qui ne s’est pas produit, ce qui est le plus grand compliment que les ops peuvent recevoir.

Erreurs courantes : symptômes → cause racine → correctif

1) « L’utilisation GPU est faible, donc mon GPU est mauvais »

Symptômes : 50–70 % d’utilisation GPU en 1080p, plateau de FPS, un cœur CPU proche de 100 %.

Cause racine : CPU-bound (thread principal ou overhead pilote). Le GPU attend du travail.

Correctif : Augmentez la résolution ou activez des features GPU plus lourdes pour confirmer l’évolutivité ; réduisez les réglages coûteux côté CPU (distance de vue, foules) ; upgrade CPU/ram si vous voulez plus de FPS.

2) « Mon CPU n’est qu’à 35 %, donc il ne peut pas être la limite »

Symptômes : Le CPU global semble correct, mais le temps par frame est incohérent ; GPU pas pleinement utilisé.

Cause racine : Un thread chaud unique est le goulot ; les moyennes masquent la saturation par cœur.

Correctif : Inspectez l’utilisation par cœur ; trouvez le thread limitant ; optimisez la performance mono-thread et réduisez les sources de contention.

3) « Baisser les réglages devrait toujours augmenter les FPS »

Symptômes : Baisser les réglages ne change rien en 1080p ; FPS inchangés, utilisation GPU décroît.

Cause racine : Vous étiez déjà limité par le CPU. Baisser les réglages a supprimé le travail GPU mais n’a pas changé le travail CPU.

Correctif : Si vous voulez plus de FPS, traitez cela comme un problème CPU : tuning mémoire, upgrade CPU, réglages moteur qui réduisent la charge CPU, ou acceptez un cap.

4) « Les saccades doivent venir de mon SSD »

Symptômes : Hitchs aléatoires, particulièrement en tournant ; le SSD est « rapide sur le papier ».

Cause racine : Souvent compilation de shaders côté CPU, création de PSO, ou coordination de streaming ; parfois un antivirus scannant le dossier du jeu.

Correctif : Vérifiez l’await IO ; vérifiez les tâches en arrière-plan ; précompilez les shaders si possible ; excluez les dossiers du jeu du scan en temps réel quand c’est approprié.

5) « Un nouveau pilote a réduit mon FPS, donc c’est le GPU »

Symptômes : 4K inchangé, 1080p pire ; pics de frametime augmentés ; clocks GPU normales.

Cause racine : Régression côté CPU du pilote ou comportement de scheduling/locking différent.

Correctif : Rétablissez la version précédente et comparez avec des runs consistants ; gardez un processus canari ; remontez au fournisseur avec des preuves de temps par frame et par cœur, pas des captures d’écran d’utilisation.

6) « La vitesse du lien PCIe n’a pas d’importance »

Symptômes : FPS moyen correct, pires 1% lows ; saccades lors de heavy streaming ; perf étrange après changements hardware.

Cause racine : GPU fonctionnant à x4/x8 de manière inattendue, ou négocié sur une génération inférieure à cause du BIOS/slot/câble/riser.

Correctif : Vérifiez la largeur/vitesse du lien ; réinsérez le GPU ; évitez les risers douteux ; définissez explicitement le mode PCIe si l’auto-négociation est capricieuse.

7) « FPS illimités, c’est toujours mieux »

Symptômes : FPS moyen élevé mais mauvais pacing ; ressenti d’entrée incohérent ; système chauffe.

Cause racine : Le CPU tourne à fond ; le jitter d’arrière-plan devient visible ; le comportement de la file de rendu peut aggraver la latence.

Correctif : Utilisez un cap de frame légèrement en dessous du refresh ; optimisez pour le 99e percentile stable du temps par frame, pas le FPS de pointe.

Check-lists / plan pas à pas

Pas à pas : prouver le goulot (ne pas deviner)

1. Désactivez temporairement les caps : Coupez le vsync, retirez les caps FPS, assurez-vous que le VRR ne vous colle pas à un plafond.
2. Exécutez une scène reproductible : Même carte, même trajectoire de caméra, même durée.
3. Testez 1080p → 1440p → 4K : Gardez les réglages identiques. Enregistrez FPS et 1% lows.
4. Enregistrez les temps par frame : Capturez temps CPU et GPU si vos outils le permettent.
5. Vérifiez l’utilisation CPU par cœur : Cherchez un thread chaud qui sature.
6. Contrôlez les thermiques : Assurez-vous qu’il n’y a pas de throttle et que les clocks sont stables.
7. Contrôlez l’état du PCIe : Confirmez x16 et la génération attendue.

Pas à pas : si vous êtes CPU-bound en 1080p et voulez plus de FPS

1. Priorisez IPC et boost CPU : Une forte performance mono-thread vaut mieux que plus de cœurs au-delà d’un certain point.
2. Corrigez la configuration mémoire : Activez XMP/EXPO correct et stable ; évitez les kits mélangés.
3. Réduisez les réglages lourds côté CPU : Distance de vue, densité de foule, détails physiques, ombres (une partie du travail d’ombre est côté CPU), options de tick de simulation.
4. Réduisez la pression des draw calls : Les réglages qui diminuent la densité d’objets ou le feuillage aident.
5. Capez les FPS intentionnellement : Mettez un cap que vous pouvez soutenir avec de bons 1% lows. Un 180 stable vaut mieux qu’un 240 instable.
6. Éliminez les sources de jitter : Overlays, capture, logiciels RGB, lecture vidéo dans les navigateurs — tout ce qui se réveille souvent.

Pas à pas : si vous êtes GPU-bound en 4K et voulez mieux visuellement ou des FPS plus réguliers

1. Utilisez la mise à l’échelle : Préférez les modes DLSS/FSR/XeSS qui préservent le détail sans forcer le natif.
2. Ciblez les passes coûteuses : Ray tracing, AO lourd, ombres en ultra et réflexions haut de gamme dominent souvent.
3. Surveillez l’utilisation VRAM : Le surcommit VRAM peut provoquer des hitchs et du paging.
4. Privilégiez des temps par frame constants : Réglez pour le 99e percentile en réduisant les paramètres qui provoquent des pics, pas seulement la charge moyenne.

FAQ

1) « Goulot d’étranglement CPU » est-ce la même chose que « mon CPU est trop lent » ?

Pas toujours. Cela peut être « CPU trop lent », mais aussi overhead pilote, un choke mono-thread, ou du jitter OS. Le symptôme est la famine du GPU.

2) Pourquoi mon upgrade GPU aide en 4K mais pas en 1080p ?

La 4K augmente suffisamment le travail GPU par image pour que le GPU devienne l’étape la plus lente. En 1080p, le GPU termine vite et attend que le CPU l’alimente.

3) Si je suis CPU-bound, dois-je augmenter les réglages graphiques ?

Si vous êtes CPU-bound et déjà satisfait du FPS, oui : augmenter la charge GPU peut améliorer la qualité d’image « gratuitement » parce que le CPU limitait déjà.
Si votre objectif est le maximum de FPS, augmenter les réglages ne vous aidera pas.

4) Pourquoi baisser la résolution réduit parfois les saccades ?

Cela peut réduire la pression GPU et la bande passante VRAM, ce qui peut lisser des pics GPU-bound. Mais si la saccade vient du CPU (compilation de shaders, streaming), changer la résolution ne la corrigera peut-être pas.

5) Plus de cœurs CPU résoudront-ils les goulots 1080p ?

Parfois, mais pas systématiquement. Beaucoup de jeux sont limités par un ou deux threads chauds. Vous voulez une forte performance mono-thread et une faible latence mémoire, pas seulement plus de cœurs.

6) DX12/Vulkan sont-ils toujours meilleurs pour les goulots CPU ?

Non. Ils peuvent réduire l’overhead si le moteur les utilise correctement, mais ils transfèrent aussi la responsabilité au jeu. Certains titres tournent mieux en DX11 grâce à des chemins pilotes plus matures.

7) Pourquoi mon usage CPU est bas mais les FPS sont plafonnés ?

Parce que les moyennes masquent les threads chauds et parce que vous pouvez atteindre un limiteur explicite : vsync, cap in-game, cap pilote ou plafond VRR. Vérifiez aussi le throttling thermique.

8) Quel est le test le plus rapide pour confirmer CPU vs GPU bound ?

Augmentez la résolution en gardant les réglages constants. Si les FPS restent presque identiques, CPU-bound. Si les FPS chutent, GPU-bound.

9) De la RAM plus rapide et des timings serrés comptent-ils vraiment ?

Dans les scénarios CPU-bound à haut FPS, oui. La latence mémoire affecte la vitesse à laquelle les threads chauds traversent l’état du jeu, construisent les command buffers et manipulent les données de draw calls.
Ce n’est pas magique, mais c’est mesurable.

10) Dois-je capper les FPS même si je veux faible latence ?

Souvent oui. Un cap intelligent (légèrement en dessous du refresh) peut réduire le queueing, stabiliser les temps par frame et diminuer la thermique CPU. Le résultat peut sembler plus réactif que le chaos non limité.

Conclusion : prochaines étapes qui fonctionnent vraiment

Les CPU créent des goulots pour les GPU en 1080p parce que le travail GPU par image diminue tandis que l’orchestration CPU ne change pas beaucoup. En 4K, le coût pixel explose,
le GPU devient l’étape lente et les péchés du CPU sont cachés derrière un mur de shading et de bande passante.

Faites la chose disciplinée :

• Prouvez si vous êtes CPU-bound ou GPU-bound avec la montée en résolution et les temps par frame.
• Si vous êtes CPU-bound en 1080p haut FPS, investissez dans le boost/IPC du CPU, la configuration mémoire et les réglages lourds côté CPU — pas dans un GPU d’un cran supérieur.
• Si vous êtes GPU-bound en 4K, cessez de forcer le natif quand un bon upscaler vous apporte de la marge avec moins de compromis.
• Adoptez une routine de benchmark ennuyeuse et reproductible. Elle empêche les régressions perf et vous évite de vous disputer autour de graphes d’utilisation.