Chutes de FPS soudaines dans les jeux : trouver la vraie cause

C'était 140. Maintenant c'est 70, et ça y reste jusqu'à ce que tu relances le jeu — ou jusqu'à ce que tu t'arrêtes, que tu laisses la machine refroidir, et que tu reviennes pour la retrouver comme neuve.

C'est un problème différent d'une saccade, et la confusion entre les deux fait perdre des semaines. Une saccade, c'est une image en retard dans un run par ailleurs sain — si c'est ça que tu as, Pourquoi les jeux saccadent sous Windows 11 est la page qu'il te faut. Une chute, c'est un changement durable de la quantité de travail que la machine abat par seconde, et presque tout ce qui suit s'annonce de lui-même si tu regardes les bons chiffres pendant que ça se produit.

D'abord, la phrase honnête. Rien sur cette page ne rend un jeu plus rapide. Elle montre trois traces que Windows garde déjà — les réinitialisations du pilote d'affichage, le firmware qui maintient la fréquence du processeur vers le bas, et les plafonds du processeur dans ton mode de gestion de l'alimentation actif —, que le scan des saccades de w0a lit pour toi, et comment lire toi-même ces trois traces en quelques minutes.

Les trois questions qui découpent tout le sujet

Avant de toucher au moindre réglage, réponds à celles-ci — chacune élimine à peu près la moitié de la liste.

Est-ce que ça se rétablit tout seul ? Une chute qui disparaît après une minute sans bouger, ça pointe vers la chaleur ou une tâche en arrière-plan. Une chute qui persiste jusqu'au redémarrage du jeu, ça pointe vers l'état interne du jeu ou un événement du pilote.
Est-ce que ça arrive dans tous les jeux ou dans un seul ? Tous les jeux, ça désigne la machine. Un seul jeu, ça désigne les réglages de ce jeu, sa mise à jour ou ses serveurs.
Est-ce que ça suit le temps passé en session, ou un endroit de la carte ? Le temps, ça veut dire la chaleur et l'alimentation. Un endroit, ça veut dire que la scène est devenue plus lourde, ou que quelque chose se charge.

Ensuite, regarde les fréquences et les températures pendant que ça se produit, pas après. Une chute invisible après coup est évidente en direct : soit une fréquence est tombée, soit non.

La chaleur et le plafond de puissance

Une cause à écarter quand « ça chute au bout de vingt minutes ».

Les puces ne tombent pas en panne quand elles chauffent, elles ralentissent. Quand une température ou une limite de puissance est atteinte, la fréquence est tirée vers le bas et maintenue là aussi longtemps que la condition dure. C'est le firmware qui prend cette décision lui-même — la protection de la carte mère ou du processeur, pas Windows — donc rien dans le Gestionnaire des tâches ne l'explique. Côté graphique, le pilote donne la raison si tu la lui demandes sous charge : protection thermique, une limite de puissance réglée en dessous de la valeur d'origine, un programme qui demande au pilote de ralentir, ou un connecteur d'alimentation PCIe mal enfoncé.

Comment le savoir : ça corrèle avec la durée de session et la température de la pièce, et la fréquence est visiblement plus basse pendant la chute qu'au départ.

Ce que tu fais : le montage du ventirad, la poussière, la circulation d'air dans le boîtier. Ensuite, vérifie si une limite de puissance a été baissée exprès — dans le firmware, dans un utilitaire du fabricant, ou dans un profil de carte graphique enregistré.

La machine a changé d'état d'alimentation

Les portables le font de la manière la plus visible : débranche le chargeur et la plateforme passe à un autre jeu de limites. Ça arrive aussi sur les tours — un mode de gestion de l'alimentation modifié, le parking des cœurs ou un plafond d'état du processeur laissé par un vieux script de réglage, un plan revenu en arrière après une mise à jour de Windows.

Comment le savoir : la chute commence sur un événement — un débranchement, un capot refermé, une sortie de veille, un redémarrage — pas sur une température.

Ce que tu fais : remets les valeurs par défaut du plan lui-même plutôt que d'inventer de nouvelles valeurs. La page Fix a des cartes pour le mode de gestion de l'alimentation et pour les paramètres d'alimentation du processeur, et chacune réécrit sans condition la valeur par défaut de Windows, quel que soit l'outil qui l'a changée.

Une réinitialisation du pilote

L'écran devient noir une seconde ou deux, revient, et tout est plus lent — ou le jeu s'est fermé. Windows a enregistré que le pilote d'affichage s'était bloqué et avait été réinitialisé.

Comment le savoir : ça laisse une trace nette, et le scan des saccades indique combien de réinitialisations ont eu lieu dans la dernière journée. La piste mène en général à un overclocking ou au refroidissement, pas à un logiciel.

Ce que tu fais : si tu as appliqué un offset mémoire ou cœur, divise-le par deux et teste une partie ; remets-le à zéro et teste encore. Récupération après plantage GPU couvre le reste, y compris comment remettre la valeur par défaut de Windows si un ancien outil a augmenté le délai au lieu de corriger la cause.

Trois traces que Windows garde déjà

1. Une réinitialisation du pilote d'affichage (événement 4101)

Quand le pilote d'affichage cesse de répondre et est réinitialisé, Windows écrit l'événement 4101 dans le journal d'événements System. Le scan des saccades compte ceux des dernières 24 heures et les rapporte comme son seul constat critique ; au-delà de dix, il dit « 10+ » au lieu de faire semblant de connaître le chiffre exact. Si le journal lui-même ne peut pas être lu, le scan dit que la vérification n'a pas pu s'exécuter au lieu de déclarer la machine propre.

Pour regarder toi-même, dans PowerShell :

Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Display'] and (EventID=4101) and TimeCreated[timediff(@SystemTime) <= 86400000]]]" -MaxEvents 10

S'il n'y en a aucun, PowerShell répond par une erreur indiquant qu'aucun événement ne correspond aux critères de sélection : c'est la réponse « aucun dans la dernière journée ». S'il dit qu'il ne peut pas lire le journal, lance PowerShell en tant qu'administrateur et réessaie.

Le retour en arrière est celui de la section ci-dessus : baisse ou retire un overclocking, regarde le refroidissement, et Récupération après plantage GPU si un ancien outil a relevé le délai d'expiration du pilote. w0a ne relèvera pas ce délai de lui-même : un watchdog plus long ne fait que rallonger chaque gel, et désactiver la récupération la supprime complètement.

2. Le firmware a maintenu la fréquence vers le bas (événement 37)

L'événement 37 de Microsoft-Windows-Kernel-Processor-Power, c'est le firmware qui consigne qu'il a abaissé la fréquence du processeur et l'a maintenue là pendant des secondes entières d'affilée ; le texte de l'événement lui-même dit pendant combien de temps. C'est important parce qu'une lecture de température ne montre que le moment où tu regardes : une machine qui a bridé sa fréquence il y a une heure et qui a refroidi depuis paraît parfaitement saine, et cet événement est la seule trace de cette heure-là qui lui reste.

Le scan compte ces événements sur les dernières 24 heures, uniquement sur secteur — sur batterie, le même événement, c'est la plateforme qui fait son travail — et avertit à partir de trois. Un ou deux sont courants dans les premières secondes après le démarrage, pendant que la carte mère stabilise ses limites de puissance.

Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Kernel-Processor-Power'] and (EventID=37) and TimeCreated[timediff(@SystemTime) <= 86400000]]]" -MaxEvents 20

Garde le nom du fournisseur dans le filtre. D'autres composants utilisent le numéro 37 pour des événements sans rapport, et un compte sans le fournisseur ne veut rien dire.

Si tu en trouves toute une série, la cause est la chaleur ou une limite de puissance, comme dans la section sur la chaleur ci-dessus ; Températures CPU et GPU en jeu explique quoi lire, et sur un portable PC portable gamer plus lent qu'il ne devrait traite du chargeur et des modes d'alimentation.

3. Le plan actif plafonne le processeur

Le nom d'un plan n'est pas ce qui tourne. Un plan haute performance avec l'état maximal du processeur à 80 % est une machine plafonnée qui porte la bonne étiquette. Le scan lit quatre réglages dans la section processeur du plan qui est actif, sur secteur :

Réglage (le nom qu'utilise powercfg)	Ce que le scan considère comme un plafond	Ce que ça veut dire
`PERFBOOSTMODE`	0	Turbo désactivé : le processeur ne dépasse jamais sa fréquence nominale.
`PROCTHROTTLEMAX`	de 1 à 99	Un plafond pour la fréquence, en pourcentage.
`IDLEDISABLE`	1	États de repos désactivés. w0a compte cela comme une limite, pas comme un réglage de performance, avec le raisonnement que sans états de repos il ne reste plus de marge thermique dans laquelle le boost peut monter. C'est un raisonnement tiré du fonctionnement du boost, pas une mesure.
`CPMINCORES`	de 1 à 99	Parking des cœurs. Pas rapporté sur les processeurs hybrides, où c'est l'un des leviers dont Windows se sert pour placer le travail, ni sur les processeurs V-Cache à deux chiplets, où c'est ainsi que le pilote garde un jeu sur le chiplet doté du cache. Voir Ryzen X3D, Game Bar et parking des cœurs.

Le scan lit ces réglages par l'interface d'alimentation de Windows et non par powercfg, parce que sur une installation standard deux d'entre eux sont masqués et powercfg n'affiche absolument rien pour eux. S'il ne peut lire aucun des quatre, le scan dit qu'il n'a pas pu mesurer, pas que le plan est propre.

Pour regarder toi-même, dans l'invite de commandes ou dans PowerShell :

powercfg /getactivescheme
powercfg /query SCHEME_CURRENT SUB_PROCESSOR PROCTHROTTLEMAX
powercfg /query SCHEME_CURRENT SUB_PROCESSOR IDLEDISABLE
powercfg /query SCHEME_CURRENT SUB_PROCESSOR PERFBOOSTMODE
powercfg /query SCHEME_CURRENT SUB_PROCESSOR CPMINCORES

Comment lire les réponses :

La valeur est sur les deux dernières lignes de la réponse, en hexadécimal : la première est la valeur sur secteur (AC), la seconde la valeur sur batterie (DC). 0x00000064 vaut 100, 0x00000050 vaut 80, 0x00000001 vaut 1, 0x00000000 vaut 0.
Les noms des réglages autour des chiffres s'affichent dans la langue de ton Windows ; les alias que tu tapes (SUB_PROCESSOR, PROCTHROTTLEMAX) sont les mêmes dans toutes les langues.
Si toute la réponse tient en une seule ligne avec le GUID du plan et rien en dessous, la commande demande un réglage que Windows masque sur cette installation. Ça ne dit rien de sa valeur ; le scan des saccades est le moyen de la lire.

Le retour en arrière, réglage par réglage :

PROCTHROTTLEMAX ou CPMINCORES écrits dans les plans propres à Windows : la carte Paramètres d'alimentation du processeur remet l'état minimal et l'état maximal du processeur ainsi que le parking des cœurs à la valeur par défaut que déclare chaque plan, puis réapplique le plan actif, parce que Windows lit les valeurs d'un plan quand il est activé.
Un plafond qui vit dans un plan créé par un outil quelconque : la carte Plan d'alimentation et batterie passe d'abord sur Utilisation normale, pour que ce plan cesse d'être celui qui tourne, et supprime les plans propres à w0a.
PERFBOOSTMODE ou IDLEDISABLE : aujourd'hui, aucune carte de réparation ne remet ces deux-là par leur nom. Le retour en arrière, c'est le plan lui-même, avec powercfg, à la valeur que le plan déclare comme valeur par défaut.

C'est arrivé juste après une mise à jour

Deux choses très différentes se cachent ici.

Une mise à jour du jeu ou du pilote invalide le cache de shaders, et le jeu recompile pendant que tu joues. La fréquence d'images est réellement plus basse pendant un moment, puis elle ne l'est plus. Ça s'estompe ; c'est ça, la signature. Saccades de compilation des shaders explique pourquoi, et pourquoi il ne faut pas faire de benchmark dans cette fenêtre.

Une régression sur une branche de pilote ne s'estompe pas. Les fabricants les reconnaissent par écrit — les notes de version portent des entrées du genre « performances inférieures dans ce titre sur les branches plus récentes que X ». Ne rétrograde pas par réflexe : termine tes mises à jour, mesure sur ta propre machine, et n'envisage une autre version que si tu peux documenter la régression toi-même.

Autre chose s'est mis à tourner

Une analyse planifiée, un processus de mise à jour en train de décompresser, une archive qui s'extrait, un export vidéo. Ça fait la queue pour les mêmes cœurs que le jeu et, contrairement à un à-coup, ça ne disparaît pas entre deux images — c'est souvent reproductible à une certaine heure de la journée. L'utilisation totale du processeur est le mauvais chiffre à regarder : un seul cœur saturé sur une machine à huit cœurs donne un total modeste. Attends que ça passe, ou déplace ce travail.

La fréquence d'images n'a pas vraiment chuté

Une limite d'images. Si le chiffre sur lequel tu retombes est exactement ta fréquence de rafraîchissement, la limite réglée dans le jeu ou une limite posée côté pilote, rien n'est en goulot d'étranglement — tu es au plafond que tu as demandé.

La résolution dynamique. Un jeu qui ajuste lui-même sa résolution de rendu pour tenir une fréquence d'images cible affiche un compteur stable pendant que c'est la qualité d'image qui bouge à la place.

C'est un seul jeu, et le compteur a l'air bon

Alors la chute n'est peut-être pas du tout sur ta machine. Une partie en ligne se dégrade pour tout le monde sur le serveur en même temps, et un problème réseau n'est pas un problème de fréquence d'images : des paquets qui arrivent en retard font saccader le monde autour de toi pendant que ta machine continue de dessiner à pleine vitesse. Si les temps d'image restent sains pendant l'événement, arrête de regarder le PC.

Si au contraire la fréquence d'images est simplement plus basse qu'elle ne devrait l'être pendant que la carte graphique ne fait rien, c'est un diagnostic à part avec sa propre liste : GPU pas à 100 % la parcourt dans l'ordre.

Un run qui produit une réponse

Prends une capture d'une session normale avant que quoi que ce soit n'aille mal, et garde-la. Lire le benchmark explique comment, et pourquoi la moyenne y est le chiffre le moins utile.
Quand la chute arrive, note les fréquences et les températures pendant, pas après.
Change une seule chose, puis reproduis la même scène et la même durée de session.
Juge par rapport à ta propre variation d'un run à l'autre. Si trois runs sans changement varient plus que l'écart qui te fait plaisir, tu as trouvé du bruit.

Ce qu'il ne faut pas faire face à une chute

N'augmente pas le délai de récupération du pilote graphique pour masquer une réinitialisation : ça transforme une récupération courte en blocage plus long et ça efface la preuve. Ne désactive pas des cœurs ni le multithreading simultané sur la foi d'un guide sans sources — tu échangerais une capacité multi-cœur connue contre un gain dont personne n'a publié la méthode. Et n'applique pas les valeurs de gestion mémoire du noyau comme correctif de performance ; w0a refuse de les écrire, et aucune mesure ne les appuie.

Il en va de même pour les réglages d'alimentation : aucun des quatre ci-dessus n'est un interrupteur de « performance » à basculer dans l'autre sens. Turbo désactivé, le processeur reste à sa fréquence nominale, et le scan de w0a lui-même signale aussi les états de repos désactivés comme une limite, où qu'il les trouve.