Les correctifs m’ont volé mon FPS : mythe, réalité et la vérité ennuyeuse

Mythe vs réalité : quand les correctifs font vraiment du mal

Le mythe : chaque correctif vole des FPS parce que les développeurs sont négligents ou parce que les mises à jour sont intrinsèquement « plus lourdes ». Cette histoire satisfait émotionnellement. Elle n’explique rien pour autant.

La réalité : les changements de performance après un correctif entrent dans quelques catégories, et seules certaines sont de réelles régressions. Si vous pouvez nommer la catégorie, vous pouvez la corriger — ou du moins déposer un bug qui ne sera pas ridiculisé lors du triage.

Catégorie 1 : régressions réelles (oui, ça arrive)

Une régression réelle se produit quand la nouvelle version fait plus de travail par image ou fait le même travail moins efficacement. Exemples : un chemin de rendu utilise un shader plus lent, un nouvel effet post-traitement est activé par défaut, une modification de la physique augmente les vérifications de collisions, ou un pilote change le chemin de compilation pour certains shaders.

Ce sont des problèmes réels, mesurables et généralement reproductibles sur plusieurs machines. Si vous avez des chiffres avant/après et un trajet de test stable, vous êtes en bonne position.

Catégorie 2 : effets de « chauffe » (cache de shaders et compilation de pipeline)

Beaucoup de rapports « mon FPS est mort après un correctif » ne sont que des saccades liées à la compilation des shaders. Les correctifs invalident souvent les caches de shaders, modifient les pipelines ou ajoutent de nouveaux shaders. Vos premières parties ont des accrochages. Puis ça se stabilise.

Si la plainte concerne des saccades ponctuelles plutôt qu’une baisse moyenne du FPS, pensez d’abord aux caches. Si la moyenne a chuté de 20 %, cherchez une autre cause.

Catégorie 3 : réinitialisations de paramètres et bascules silencieuses

Les mises à jour adorent réinitialiser les paramètres. Les jeux, pilotes et OS le font tous. Votre échelle de résolution change. Votre ray tracing s’active. Votre plan d’alimentation revient sur « équilibré ». Votre pilote GPU décide que vous préférez « optimal power » maintenant.

C’est la « régression » la plus fréquente parce que ce n’en est pas vraiment une. C’est de l’amnésie.

Catégorie 4 : atténuations de sécurité et changements du noyau

Certaines mises à jour réduisent volontairement les performances, en particulier les atténuations pour les problèmes d’exécution spéculative. L’impact varie fortement selon la charge de travail. Pour beaucoup de jeux, l’impact est faible ; pour certains titres CPU-intensifs ou moteurs avec beaucoup d’appels système, il peut être mesurable.

Également : changements de l’ordonnanceur du noyau, comportement des timers et réglages d’alimentation peuvent modifier les temps d’image. Vous n’avez pas besoin d’être ingénieur noyau pour le détecter ; il faut un benchmark reproductible et la patience d’isoler.

Catégorie 5 : activité d’arrière-plan non désirée

Après un correctif, les systèmes font souvent de la « maintenance » : indexation, rafales de télémétrie, reconstruction du cache de shaders, rescans antivirus, tâches d’optimisation de pilote, synchronisation cloud. Si vos saccades coïncident avec des I/O disque ou des pics CPU, cette catégorie est la suspecte principale.

Catégorie 6 : le placebo de la perception

Parfois le correctif n’a rien changé aux performances. Vous avez changé d’attention. Vous avez commencé à regarder le compteur FPS, activé un overlay de frametimes, joué sur une carte différente ou rejoint un serveur avec un autre tickrate et une latence différente.

Les humains excellent à détecter l’inconfort et sont mauvais en expériences contrôlées. Votre GPU se fiche des impressions.

Une citation pour rester honnête : idée de Peter Drucker (paraphrasée) : ce que l’on ne peut pas mesurer, on ne peut pas le gérer. Mesurer, c’est arrêter de se disputer avec sa mémoire.

Ce que les correctifs changent réellement (et pourquoi le FPS est fragile)

Le FPS n’est pas un seul nombre. C’est le résultat d’une chaîne avec plusieurs maillons, chacun ayant ses modes de défaillance. Votre « FPS moyen » peut rester correct tandis que les temps d’image varient et que le jeu paraît horrible. Ou vos 1% lows s’effondrent alors que les moyennes semblent normales. Ou votre latence d’entrée augmente et vous appelez ça du « lag » même si le réseau va bien.

Jeux : contenu, shaders et travail CPU

Les correctifs de jeu peuvent modifier :

• Shaders et matériaux : nouvelles permutations, nouveaux flags de compilation, chemins d’échantillonnage de textures différents.
• Fonctions de rendu : activation d’options plus coûteuses par défaut, changement des seuils de LOD, ajout de passes d’occlusion/visibilité.
• Simulation : pas de physique, fréquences d’IA, nombres de particules, complexité du mixage audio.
• Streaming d’assets : nouvelle compression, heuristiques de streaming modifiées, assets plus volumineux, tailles de prélecture différentes.
• Télémétrie/anti-triche : pilotes en mode noyau supplémentaires, contrôles plus fréquents, coût CPU plus élevé dans certains cas.

Pilotes : changements de compilateur et comportement d’alimentation

Les pilotes GPU sont essentiellement des compilateurs plus un ordonnanceur plus un gestionnaire d’alimentation. Une mise à jour de pilote peut :

• Changer la sortie de compilation des shaders pour des jeux spécifiques (parfois plus rapide, parfois non).
• Modifier le comportement des fréquences boost sous certaines conditions thermiques ou de puissance.
• Réinitialiser les profils par-jeu, y compris les limiteurs de fréquence et les modes faible latence.
• Changer la manière dont les caches de pipeline DX12/Vulkan sont stockés et réutilisés.

Mises à jour d’OS : noyau, ordonnanceur et services « utiles »

Les patches d’OS peuvent changer l’ordonnanceur, le comportement des timers, la gestion des défauts de page, les chemins de code du système de fichiers, les politiques de compression mémoire et les atténuations de sécurité. Même si le surcoût brut est faible, il peut se traduire par des temps d’image incohérents — surtout sur des CPU déjà proches de la limite.

Et puis il y a les trucs ennuyeux : un correctif déclenche un scan en arrière-plan, qui sature la file d’attente du SSD, qui retarde le streaming d’assets, ce qui provoque des saccades. Ce n’est pas une « régression graphique ». C’est la file d’attente de stockage qui dit « non ».

Blague n°1 : un correctif n’a pas « volé » votre FPS ; il l’a simplement « réaffecté » au département indexation arrière-plan.

Modèle mental : trouvez le plus long poteau par image

Chaque image a un budget. À 60 FPS vous avez 16,67 ms. À 120 FPS vous avez 8,33 ms. Dépassez le budget et vous avez des saccades, des frames sautées, ou les deux.

La question n’est pas « un correctif a-t-il baissé le FPS ? » La question est « quelle étape dépasse désormais le budget ? » Thread principal CPU ? Thread de rendu ? GPU ? I/O disque ? Overhead pilote ? Latence d’interruption/DPC ? Throttling thermique ?

L’ingénierie de performance, c’est surtout du refus : refusez de deviner, refusez de courir après des fantômes, refusez de réparer ce que vous n’avez pas mesuré.

Faits intéressants et contexte historique

• Les atténuations de sécurité peuvent être mesurables : Après 2018, les atténuations pour les exécutions spéculatives (ex. Spectre/Meltdown) ont introduit un vrai surcoût dans certaines transitions noyau/utilisateur et dans les patterns I/O, et certains workloads l’ont remarqué.
• La saccade due à la compilation de shaders est ancienne : Elle existait bien avant les APIs modernes ; les pipelines récents facilitent simplement la rencontre avec ce problème quand les caches sont invalidés ou que les pilotes changent la génération de code.
• La régulation du frame pacing compte plus que le FPS moyen : Beaucoup de moteurs « donnent l’impression » d’être pires après des changements qui augmentent la variance, même si la moyenne reste similaire. Les 1% lows sont devenus une métrique grand public pour une raison.
• Les mises à jour Windows peuvent réinitialiser les plans d’alimentation : Les mises à jour de fonctionnalités et certaines installations de pilotes remettent souvent à zéro les plans d’alimentation ou les profils GPU par défaut, surtout sur les portables.
• Les pilotes livrent des profils spécifiques aux jeux : Les deux grands fournisseurs GPU maintiennent des optimisations par titre ; les mises à jour peuvent aider un titre et en pénaliser un autre à cause des heuristiques et des changements de compilateur.
• DX12/Vulkan ont déplacé du travail vers l’application : La promesse d’un overhead pilote réduit signifie aussi que les jeux peuvent compiler des pipelines à des moments inopportuns si ce n’est pas soigneusement conçu.
• Le stockage est devenu plus rapide, les attentes aussi : Le NVMe a réduit les temps de chargement, mais cela a aussi encouragé un streaming plus agressif. Quand le stockage a des ratés, ils sont plus visibles parce que la chaîne est plus serrée.
• L’anti-triche s’est approfondi : De plus en plus de titres utilisent des composants en mode noyau. Ils peuvent interagir avec les pilotes et les fonctions de sécurité, parfois en produisant du bruit d’ordonnancement ou de la contention.
• La maintenance en arrière-plan n’est pas nouvelle : Indexation, mises à jour et scans ont toujours existé, mais les systèmes modernes en font plus automatiquement et plus fréquemment.

Mode d’emploi pour un diagnostic rapide

Voici l’ordre que j’utilise quand quelqu’un dit « le correctif a tué les performances » et que je veux une réponse en 15 minutes, pas un week-end.

Premier point : classer la douleur (moyenne vs saccades vs latence)

• FPS moyen en baisse : probablement un goulot soutenu (GPU limité, CPU limité, plafond puissance/thermique, nouvelle charge de travail).
• Saccades / pics de frametime : probablement compilation, streaming d’assets, pagination, I/O d’arrière-plan, problèmes DPC pilote.
• Entrée ressentie comme retardée : peut être un changement de limiteur de trames, vsync, profondeur de file de rendu, bascule du mode faible latence, ou saturation CPU.

Deuxième point : vérifier ce qui a changé (paramètres, pilotes, alimentation)

1. Vérifiez que les paramètres graphiques du jeu n’ont pas été réinitialisés (échelle de résolution, RT, DLSS/FSR, limites de fréquence).
2. Confirmez si la version du pilote GPU a changé (et si le profil par-jeu a été réinitialisé).
3. Confirmez que le mode d’alimentation de l’OS n’a pas été rétabli. Sur les portables, vérifiez aussi si vous êtes sur batterie et coincé en mode TDP réduit.

Troisième point : identifier le goulot avec un overlay et un graphique

Utilisez un outil qui affiche le temps GPU, le temps d’image CPU et l’utilisation VRAM/RAM, plus un graphe de frametimes. Si le temps GPU est supérieur au temps CPU, vous êtes limité par le GPU. Si le temps CPU est supérieur, vous êtes limité par le CPU. Si les pics de frametime se corrèlent avec des I/O disque ou des défauts de page, c’est du streaming/pagination.

Quatrième point : éliminer le bruit d’arrière-plan

Juste après un correctif, laissez le système inactif pendant 10–20 minutes, branché, écran allumé, pour qu’il termine l’indexation/les scans. Testez ensuite. Si les performances « reviennent magiquement », vous n’avez rien réparé ; vous avez juste attendu la maintenance.

Cinquième point : reproduire avec un test stable

Même carte. Même scène. Même trajectoire caméra si possible. Même résolution. Même configuration pilote. Si vous ne pouvez pas reproduire de manière fiable, vous ne pouvez pas diagnostiquer de manière fiable.

Sixième point : n’accusez le correctif qu’ensuite

Si vous pouvez reproduire après plusieurs redémarrages, avec les tâches d’arrière-plan calmes, paramètres vérifiés et un benchmark stable, alors vous pouvez dire de manière crédible « cette version est plus lente ». C’est le moment de déposer un rapport exploitable (ou de revenir en arrière).

Tâches pratiques : commandes, sorties, décisions

Voici des vérifications réelles que je ferais sur une machine de jeu Linux ou une station de travail effectuant des charges GPU. Si vous êtes sur Windows, les idées restent valables, mais les commandes diffèrent. Le but est d’arrêter de deviner et de commencer à restreindre.

Tâche 1 : Confirmer la version du noyau et de l’OS (a-t-on vraiment patché ?)

cr0x@server:~$ uname -a
Linux cr0xbox 6.5.0-14-generic #14~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Ce que ça signifie : Version et variante du noyau. Un changement de noyau peut modifier l’ordonnanceur, les atténuations et les interactions avec les pilotes.

Décision : Si les performances ont changé juste après une mise à jour du noyau, testez le noyau précédent depuis le bootloader, ou installez un noyau LTS pour comparer.

Tâche 2 : Lister les mises à jour de paquets récentes (qu’est-ce qui a changé la nuit dernière)

cr0x@server:~$ grep " upgraded " /var/log/dpkg.log | tail -n 8
2026-01-09 03:12:10 upgraded linux-image-6.5.0-14-generic:amd64 6.5.0-13.13~22.04.1 6.5.0-14.14~22.04.1
2026-01-09 03:12:12 upgraded linux-modules-6.5.0-14-generic:amd64 6.5.0-13.13~22.04.1 6.5.0-14.14~22.04.1
2026-01-09 03:12:20 upgraded nvidia-driver-550:amd64 550.54.14-0ubuntu0.22.04.1 550.67-0ubuntu0.22.04.1
2026-01-09 03:12:35 upgraded mesa-vulkan-drivers:amd64 24.0.5-1~22.04.2 24.0.6-1~22.04.2

Ce que ça signifie : Preuves concrètes de ce qui a changé : noyau, pilote NVIDIA, Mesa Vulkan.

Décision : Si le noyau et la pile GPU ont tous deux changé, isolez : conservez le noyau et changez la version du pilote (ou inversement). Ne déboguez pas deux variables en même temps.

Tâche 3 : Vérifier l’état du pilote GPU et du runtime (le pilote est-il sain ?)

cr0x@server:~$ nvidia-smi
Sat Jan 10 12:18:44 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.67                 Driver Version: 550.67         CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 4070        Off | 00000000:01:00.0   On  |                  N/A |
| 30%   54C    P2              85W / 200W |    2100MiB / 12282MiB  |     12%      Default |
+-----------------------------------------+------------------------+----------------------+

Ce que ça signifie : Version du pilote, états d’horloge/perf du GPU, consommation, utilisation VRAM. « Perf P2 » peut indiquer qu’il ne booste pas complètement dans certains cas.

Décision : Si les performances sont mauvaises et que le GPU est bloqué dans un état basse performance, investiguez les limites de puissance, le throttling thermique ou les paramètres de gestion d’alimentation du pilote.

Tâche 4 : Vérifier le gouverneur de fréquence CPU (classique après mise à jour « pourquoi je suis lent »)

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

Ce que ça signifie : Vous êtes fixé sur un gouverneur conservateur. Sur certains systèmes, des mises à jour ou des démons d’alimentation changent cela.

Décision : Si vous jouez ou faites du travail sensible à la latence, définissez un gouverneur orienté performance (ou corrigez la politique d’alimentation sous-jacente).

Tâche 5 : Changer le gouverneur temporairement (expérience contrôlée, pas un mode de vie)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Ce que ça signifie : Les CPU vont monter en fréquence plus agressivement. Cela peut stabiliser les frametimes pour les titres CPU-limités.

Décision : Retestez. Si les saccades diminuent et que le FPS revient, votre « régression de correctif » est une régression de politique d’alimentation.

Tâche 6 : Vérifier si vous subissez du throttling CPU (les thermiques sont une note de patch silencieuse)

cr0x@server:~$ sudo dmesg | egrep -i "throttl|thermal|overheat" | tail -n 5
[  812.223001] thermal thermal_zone0: throttling CPU, temperature too high
[  812.223114] CPU0: Package temperature above threshold, cpu clock throttled

Ce que ça signifie : Le CPU se protège. Les mises à jour peuvent changer les courbes de ventilateur, les cibles de puissance, ou simplement augmenter la charge suffisamment pour atteindre la limite.

Décision : Améliorez le refroidissement, dépoussiérez, vérifiez la pâte thermique, ajustez les limites de puissance. Aucun rollback de pilote ne battra la physique.

Tâche 7 : Identifier le throttling GPU / comportement de plafonnement de puissance

cr0x@server:~$ nvidia-smi --query-gpu=clocks.sm,clocks.gr,power.draw,power.limit,temperature.gpu,utilization.gpu --format=csv
clocks.sm [MHz], clocks.gr [MHz], power.draw [W], power.limit [W], temperature.gpu, utilization.gpu [%]
2610, 2550, 198.34, 200.00, 73, 98

Ce que ça signifie : Proche de la limite de puissance, haute utilisation. Si les horloges sont plus basses que prévu à des températures raisonnables, vous pouvez être plafonné en puissance ou atteindre une limite de tension.

Décision : Si une mise à jour de pilote a changé le comportement de boost, comparez avec le pilote précédent ou ajustez les cibles de puissance/thermiques dans des limites sûres.

Tâche 8 : Détecter la pression mémoire et l’utilisation du swap (les pics de frametime adorent le swapping)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        26Gi       1.2Gi       1.3Gi       3.8Gi       3.9Gi
Swap:          8.0Gi       2.1Gi       5.9Gi

Ce que ça signifie : Le swap est utilisé et la RAM « available » est faible. C’est une recette pour des saccades quand les assets streament et que des défauts de page arrivent.

Décision : Fermez les gros consommateurs de mémoire, augmentez la RAM, réduisez les réglages de textures ou ajustez le comportement du swap. Si un correctif a augmenté l’utilisation RAM, c’est ici que ça se voit.

Tâche 9 : Vérifier la saturation des I/O disque pendant les saccades (le stockage est souvent coupable)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0-14-generic (cr0xbox) 	01/10/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.12    0.00    3.44    6.90    0.00   71.54

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1         52.00   8200.00     0.00   0.00    8.20   157.69   40.00   6400.00     0.00   0.00   12.40   160.00   0.78  92.00

Ce que ça signifie : NVMe à 92 % d’utilisation avec des temps d’attente non triviaux. Si cela s’aligne avec les saccades, vous êtes limité par l’I/O pendant le streaming ou les tâches d’arrière-plan.

Décision : Mettez en pause les services d’arrière-plan, déplacez le jeu sur un disque plus rapide, assurez-vous que TRIM fonctionne, ou réduisez la pression de streaming (qualité des textures).

Tâche 10 : Trouver le coupable en arrière-plan (qui tape sur le disque ?)

cr0x@server:~$ sudo iotop -oPa
Total DISK READ: 35.21 M/s | Total DISK WRITE: 18.77 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2143 be/4 root     28.11 M/s   10.22 M/s  0.00 %  7.11 %  updatedb.mlocate
 1987 be/4 root      2.02 M/s    5.41 M/s  0.00 %  2.34 %  systemd-journald

Ce que ça signifie : Une mise à jour de la base de données locate ronge le disque. Journald écrit aussi. Ce genre de choses arrive souvent après des mises à jour.

Décision : Laissez-le finir, replanifiez-le ou désactivez-le pendant les sessions de jeu. Ne diagnostiquez pas un « stutter GPU » pendant que le disque est en feu.

Tâche 11 : Vérifier l’espace libre du système de fichiers (peu d’espace peut plomber les SSD)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  930G  905G   25G  98% /

Ce que ça signifie : 98 % d’utilisation. Beaucoup de SSD et de systèmes de fichiers se comportent moins bien quand ils sont presque pleins (moins d’espace pour le wear leveling et les mises à jour metadata).

Décision : Libérez de l’espace. Visez au moins 10–15 % libre sur les SSD grand public, plus si vous écrivez beaucoup.

Tâche 12 : Vérifier le calendrier TRIM (aide les performances soutenues des SSD)

cr0x@server:~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Sat 2026-01-10 09:00:01 UTC; 3h 18min ago
    Trigger: Mon 2026-01-12 00:00:00 UTC; 1 day 11h left

Ce que ça signifie : TRIM est activé hebdomadairement. Bonne hygiène de base.

Décision : Si désactivé sur des SSD, activez-le. Si le système était plein et vient d’être nettoyé, lancez fstrim et retestez.

Tâche 13 : Vérifier les tempêtes de défauts de page (streaming d’assets vs faible RAM)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 214748 1213440 142320 3568120    0    0  8012  6321 3120 8441 21  4 69  6  0
 3  0 214748 1189024 142320 3579000    0    0  9200  7000 3411 9032 24  5 65  6  0

Ce que ça signifie : Beaucoup de changements de contexte, I/O soutenu, peu de mémoire libre. Si vous voyez si/so (swap-in/out) augmenter, vous êtes en danger.

Décision : Réduisez l’utilisation mémoire, fermez les onglets du navigateur (oui, vraiment), et vérifiez s’il n’y a pas un processus d’arrière-plan devenu incontrôlable introduit par le correctif.

Tâche 14 : Vérifier la pression d’ordonnancement CPU (sommes-nous juste surchargés ?)

cr0x@server:~$ uptime
 12:24:11 up  5:42,  1 user,  load average: 11.20, 9.84, 6.91

Ce que ça signifie : Une charge moyenne proche du nombre de CPU peut aller, mais une charge bien au-dessus signifie que des tâches prêtes s’accumulent. Les jeux détestent attendre.

Décision : Identifiez ce qui consomme le CPU. Si un correctif a introduit un service qui écrase les cœurs, désactivez/le limitez.

Tâche 15 : Identifier les plus gros consommateurs CPU (les suspects habituels)

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
 4121 game.bin        285.2 18.3
 1981 baloo_file      122.4  2.1
 3777 discord          32.1  1.8
 2190 pipewire         18.7  0.4

Ce que ça signifie : Le jeu est lourd (attendu), mais un indexeur de fichiers brûle aussi du CPU. C’est une interférence sur les frametimes.

Décision : Arrêtez / replanifiez l’indexeur, puis retestez. Si le correctif a déclenché l’indexation, votre « régression » est une tâche d’arrière-plan.

Tâche 16 : Vérifier l’état des atténuations du noyau (pour ceux qui accusent les patches de sécurité)

cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines; IBPB: conditional; STIBP: disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected

Ce que ça signifie : Quelles atténuations sont actives. PTI, retpolines, IBPB, etc. Certaines atténuations impactent les transitions noyau ou certains patterns.

Décision : Ne désactivez pas bêtement les atténuations. Si vous mesurez une grosse régression et comprenez le modèle de risque, vous pouvez tester des bascules sur un système non sensible. Sinon, laissez-les activées et corrigez le vrai goulot.

Blague n°2 : désactiver des atténuations pour récupérer 5 FPS revient à enlever vos freins pour améliorer vos temps au tour — techniquement efficace, socialement déconseillé.

Trois micro-récits d’entreprise depuis le terrain

Micro-récit 1 : L’incident causé par une mauvaise hypothèse

Dans une entreprise de taille moyenne, le labo interne « soirée jeu » servait aussi de ferme de tests graphiques. Ce n’était pas un jouet : les équipes validaient des builds UI accélérés par GPU et du rendu distant. Après un cycle de correctifs de sécurité, tout le monde s’est plaint que les builds « paraissaient » plus lents. La théorie la plus bruyante était que les patches de sécurité avaient introduit un impact de performance noyau. L’histoire était toute trouvée.

Un ingénieur a rollbacké le noyau sur quelques machines et a réclamé victoire. Le graphe de frametime semblait plus lisse — brièvement. Ce n’était pas reproductible. Le rollback est devenu un rituel : « si ça saccade, bootez l’ancien noyau. » Ce n’est pas de l’ingénierie ; c’est une superstition avec un prompt de reboot.

La cause réelle était plus petite et stupide : la mise à jour a modifié la configuration du démon de profil d’alimentation de la machine. Le gouverneur CPU est passé en powersave après le reboot sur cette génération de matériel. Sous des charges éphémères, le CPU ne montait pas assez vite et le thread principal manquait les budgets d’image, créant des pics.

Une fois qu’ils ont forcé le bon gouverneur et verrouillé le profil via une politique, les performances sont revenues sur tous les noyaux. Le patch de sécurité n’a pas « volé » les FPS. L’hypothèse l’a fait : ils ont supposé que le patch touchait seulement des chemins liés à la sécurité, pas la politique système. Cette hypothèse a coûté trois jours et a instauré une culture de rollback qui a plus tard bloqué de vrais correctifs de sécurité.

Micro-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation gérait une flotte de stations Linux pour des artistes. Un lead a décidé « d’optimiser » les nuits de patch en lançant immédiatement, après les mises à jour, des tâches lourdes de maintenance : indexation de fichiers, reconstruction de catalogues d’assets et scans d’intégrité. L’idée semblait raisonnable : le faire une seule fois, hors heures, quand personne ne travaille.

Puis ils ont déplacé le patching de la nuit tardive au petit matin pour « réduire les indisponibilités ». Les tâches de maintenance ont suivi. La première heure de la journée de travail s’est transformée en festival de saccades : accrochages de viewport, pauses de compilation et lenteur générale. Les gens ont accusé le nouveau pilote. Les gens accusent toujours le nouveau pilote.

Ils ont essayé de changer les paramètres du pilote, modifier les compositeurs et pinner d’anciennes versions de Mesa. Rien n’a tenu parce que le goulot n’était pas le GPU. C’était la contention de la file d’attente stockage : les tâches de maintenance saturaient le NVMe avec des I/O aléatoires petites, et le streaming d’assets des apps créatives devait se battre pour les mêmes files.

La solution a été presque embarrassante : replanifier la maintenance aux véritables heures creuses, assigner une priorité I/O aux jobs d’arrière-plan et limiter la concurrence. La « régression » de performance a disparu sans toucher à la pile GPU. L’optimisation a échoué parce qu’elle supposait que « hors heures » était un timestamp, pas une condition. Si les utilisateurs sont actifs, ce n’est pas hors heures.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise avec un contrôle des changements strict maintenait une « image dorée » pour les stations GPU. Gouvernance ennuyeuse, beaucoup de formulaires. Les ingénieurs levaient les yeux — jusqu’à ce qu’un correctif arrive et introduise réellement une régression de performance dans une couche de traduction OpenGL/Vulkan utilisée par un outil interne.

Au lieu de paniquer, ils avaient trois choses : une baseline épinglée, un benchmark de scène reproductible et un déploiement par étapes. Le groupe de staging a attrapé la régression en un jour, avec des chiffres avant/après propres et des logs montrant exactement quels paquets avaient changé.

Ils ont bloqué le déploiement, gardé la production sur l’image connue bonne et déposé un rapport précis en amont avec un repro minimal et les versions. En attendant, ils ont validé un contournement : pinner un composant tout en appliquant le reste des correctifs de sécurité. Risque réduit, le travail a continué, personne n’a eu à « vivre avec ça ».

C’est pourquoi les pratiques ennuyeuses comptent. Les rollouts, baselines et scènes de test ne semblent pas héroïques. Ils évitent les actes héroïques.

Erreurs courantes : symptôme → cause racine → correctif

1) « Le FPS a chuté après le correctif » (mais l’échelle de résolution a été réinitialisée)

Symptôme : Le FPS moyen chute fortement ; l’utilisation GPU augmente ; les visuels semblent un peu plus nets.

Cause racine : Échelle de résolution, anti-aliasing ou ray tracing activé par défaut après le correctif.

Correctif : Revérifiez les paramètres, confirmez la résolution de rendu, restaurez le preset précédent et retestez la même scène.

2) « Ça saccade toutes les quelques secondes » (disque et indexation)

Symptôme : Pics de frametime alignés avec l’activité disque ; le FPS moyen peut être correct.

Cause racine : Indexation/scans d’arrière-plan après les mises à jour ; streaming d’assets qui entre en compétition pour les I/O.

Correctif : Identifiez le process (iotop), laissez-le finir, replanifiez-le ou réduisez sa priorité I/O. Assurez-vous d’avoir suffisamment d’espace disque libre.

3) « FPS bas seulement après reboot » (réinitialisation du gouverneur/politique)

Symptôme : Première session après reboot lente ; les horloges CPU rampent lentement ; le portable semble bridé.

Cause racine : Le gouverneur est passé en powersave/équilibré, ou le firmware/démon a rétabli des limites de puissance plateforme.

Correctif : Définissez le gouverneur / mode d’alimentation approprié, vérifiez l’alimentation secteur et les profils plateforme.

4) « Les 1% lows se sont effondrés » (pression mémoire et swap)

Symptôme : FPS moyen OK ; à-coups soudains en tournant un coin / en chargeant des zones ; le swap augmente.

Cause racine : Le correctif a augmenté la consommation RAM/VRAM ; le système commence à paginer.

Correctif : Baissez les textures, fermez les applis en arrière-plan, augmentez la RAM, assurez-vous que le swap ne thrash pas.

5) « L’utilisation GPU est basse mais le FPS est bas » (CPU-bound ou overhead pilote)

Symptôme : Le GPU tourne à 40–60 % alors que le FPS est mauvais ; un cœur CPU est saturé.

Cause racine : Goulot sur le thread principal, overhead du pilote ou contention CPU d’arrière-plan.

Correctif : Réduisez les réglages lourds côté CPU (distance de vue, foule), tuez les processus CPU-encombrants, testez un autre renderer (DX11 vs DX12/Vulkan).

6) « Le FPS est OK dans les menus, terrible en jeu » (reconstruction du cache de shaders)

Symptôme : Première partie saccade, parties suivantes s’améliorent ; pics CPU lors de nouveaux effets.

Cause racine : Cache de shaders invalidé par le correctif ou la mise à jour du pilote.

Correctif : Laissez compiler (chauffez), évitez de juger sur la première exécution, gardez les caches sur un stockage rapide, ne nettoyez pas les caches sauf pour le dépannage.

7) « Le VR saccade après la mise à jour » (sensibilité temporelle)

Symptôme : Plus de frames perdues / reprojection fréquente ; de petits pics gâchent le confort.

Cause racine : Le VR est intolérant à la variance des frametimes ; les tâches d’arrière-plan ou changements d’ordonnancement pèsent davantage.

Correctif : Éliminez l’activité d’arrière-plan, fixez un mode d’alimentation/performance stable, assurez-vous que le GPU n’est pas plafonné, retestez avec une échelle de rendu fixe.

8) « Rollback n’a pas aidé » (changements multiples et état en cache)

Symptôme : Vous avez roll-backé une chose ; le problème persiste ; tout le monde est confus.

Cause racine : Vous avez changé deux composants ou plus (noyau + pilote + jeu), ou des caches/paramètres ont persisté après le rollback.

Correctif : Changez une variable à la fois. Enregistrez les versions. Réinitialisez uniquement ce qui est pertinent (config graphique, cache de shaders si nécessaire), puis retestez.

Listes de contrôle / plan étape par étape

Étape par étape : prouver (ou infirmer) « le correctif l’a fait »

1. Verrouillez votre test : même scène, même résolution, même emplacement en jeu, même replay/demo si disponible.
2. Enregistrez les versions : build du jeu, version du pilote, version OS/noyau.
3. Capturez les frametimes : ne vous fiez pas au seul FPS moyen. Regardez les 1% lows et les pics.
4. Vérifiez les paramètres : surtout l’échelle de résolution, RT, mode d’upscaling, limiteur de trame, vsync, mode faible latence.
5. Vérifiez l’état d’alimentation : gouverneur CPU, état perf GPU, AC/batterie du portable, logs de throttling thermique.
6. Éliminez les jobs d’arrière-plan : indexation, scans antivirus, outils de sync, services de mise à jour.
7. Vérifiez la santé du stockage : espace libre, attente I/O, temps d’attente élevés, calendrier TRIM.
8. Vérifiez la pression mémoire : RAM disponible, usage swap, indicateurs de défauts de page.
9. Changez une variable : rollback du pilote ou swap du noyau ou version du jeu (quand possible). Pas les trois.
10. Retestez deux fois : la première exécution peut inclure la reconstruction des caches ; la seconde est plus proche de l’état stable.
11. Décidez : si la régression est reproductible, déposez un bug avec des chiffres ; si c’est une configuration / un problème d’arrière-plan, corrigez localement et documentez.

Checklist : actions rapides pour « je veux juste retrouver ma fluidité »

• Redémarrez une fois (oui, une fois), puis attendez 10 minutes inactives que les tâches post-update se terminent.
• Confirmez que votre mode d’alimentation / gouverneur n’est pas coincé en basse consommation.
• Vérifiez l’espace disque libre ; si vous êtes > 90 % utilisé, corrigez cela en priorité.
• Désactivez les overlays inutiles pour le test (certains introduisent un overhead mesurable).
• Chauffez la compilation des shaders en exécutant la même scène quelques minutes.
• Si le problème a commencé avec une mise à jour de pilote, testez la version précédente du pilote.

Checklist : ce qu’il faut inclure dans un rapport de bug respecté par les ingénieurs

• Versions avant/après (jeu, pilote, OS/noyau).
• Paramètres exacts et résolution, incluant le mode d’upscaler et la limite de trame.
• Étapes de repro avec une scène stable et durée recommandée d’exécution.
• FPS moyen plus 1% low et description des pics de frametime.
• Résumé matériel (CPU, GPU, RAM, type de stockage).
• Si la régression persiste après la seconde exécution (cache chauffé) ou non.

FAQ

1) Les correctifs réduisent-ils vraiment le FPS, ou c’est toujours un placebo ?

Les deux. Il existe de vraies régressions. Le placebo est aussi courant. La différence se voit à la reproductibilité avec un test contrôlé et des métriques cohérentes (frametime, 1% lows).

2) Pourquoi ça saccade juste après une mise à jour puis s’améliore ?

Invalidation du cache de shaders et maintenance d’arrière-plan. La compilation au premier lancement et l’indexation post-update sont classiques. Testez après une exécution de chauffe et après que le système soit au repos.

3) Dois-je rollbacker le pilote GPU immédiatement ?

Seulement après avoir vérifié les réinitialisations de paramètres et l’activité d’arrière-plan. Si le problème a commencé exactement avec la mise à jour du pilote et persiste après redémarrages et runs chauffés, alors oui : rollback en isolation pour tester.

4) Les atténuations de sécurité sont-elles la raison de ma perte de FPS ?

Parfois, mais rarement la première piste à vérifier pour les jeux. Mesurez d’abord. Vérifiez la politique d’alimentation, les I/O d’arrière-plan et les réinitialisations de paramètres avant de commencer à toucher aux atténuations et prendre des risques de sécurité.

5) Le FPS moyen semble OK, mais c’est pire. Quelle métrique compte ?

La cohérence des frametimes. Regardez les 1% lows et le graphe de frametime. Ce sont les pics que vous ressentez comme des accrochages, même si la moyenne est élevée.

6) Le faible espace disque peut vraiment causer des problèmes de FPS ?

Oui. Le streaming d’assets peut saccader à cause d’une I/O saturée, et les SSD peuvent se dégrader en performance quand ils sont presque pleins. Si vous êtes à 95–99 % d’utilisation, vous avez un générateur de saccades.

7) Pourquoi l’utilisation GPU est basse alors que le FPS est bas ?

Vous êtes probablement limité par le CPU ou bloqué par autre chose (overhead pilote, limite mono-thread, contention CPU d’arrière-plan). Le GPU ne peut pas travailler s’il n’est pas alimenté en travail.

8) Dois-je « optimiser » en désactivant des services et tâches d’arrière-plan ?

Soyez chirurgical. Désactivez les coupables que vous pouvez prouver interférer (indexeurs, scans) ou replanifiez-les. Ne démantelez pas votre système au hasard puis vous demandez quelle partie a cassé les mises à jour.

9) Quel est le moyen le plus rapide pour savoir si c’est CPU- ou GPU-limité ?

Utilisez un overlay affichant le temps d’image CPU et le temps GPU. Celui qui est le plus élevé est votre limite. Visez ensuite ce sous-système plutôt que de tripoter des sliders graphiques au hasard.

10) Pourquoi un correctif change-t-il mes paramètres ?

Les migrations échouent, de nouvelles options apparaissent, les valeurs par défaut changent, les profils se réinitialisent après une installation de pilote, et les fichiers de config sont régénérés. Ce n’est pas de la malveillance ; c’est l’entropie avec une note de version.

Conclusion : étapes suivantes qui fonctionnent vraiment

Si vous ne gardez qu’une chose : arrêtez de vous battre avec le calendrier. « C’est arrivé après le correctif » n’est pas la même chose que « le correctif l’a causé ». La corrélation est le point de départ d’une bonne enquête, pas sa fin.

Voici ce qu’il faut faire la prochaine fois que le FPS chute après une mise à jour :

1. Classifiez le problème (baisse moyenne vs pics de frametime vs latence d’entrée).
2. Vérifiez les paramètres et la politique d’alimentation (les trucs pas glamours cassent constamment).
3. Cherchez les I/O d’arrière-plan et les hogs CPU (la maintenance post-update est un récidiviste).
4. Mesurez avec un test stable et conservez des preuves avant/après.
5. Changez une variable à la fois (rollback pilote, swap noyau, ou version du jeu—choisissez une seule).

Si c’est une vraie régression, vous le prouverez. Si ce n’est pas le cas, vous le réparerez quand même — plus vite, avec moins de folklore. Voilà la vérité ennuyeuse. L’ennui fonctionne. L’ennui livre.