Pourquoi les jeux saccadent sous Windows 11 (et comment trouver la vraie cause)

Ton compteur affiche 160. Le jeu sursaute quand même — une fraction de seconde où l'image s'arrête, où ta visée atterrit à un endroit où tu ne l'as pas mise, puis tout va bien à nouveau. Le compteur n'a jamais bougé, et c'est pour ça que rien de ce que tu fais pour le faire monter n'aide.

Cet écart, c'est tout le sujet de cette page. Une saccade, c'est une image arrivée en retard, pas une fréquence d'images basse. Un compteur d'images fait une moyenne sur une seconde, donc une image qui a pris 90 ms disparaît à l'intérieur des 159 images courtes qui l'entourent. Le chiffre qui décrit ce que tu as ressenti, c'est le temps d'image, et une saccade est une image beaucoup plus lente que ses voisines.

D'abord, la phrase honnête. Deux des dix causes ci-dessous correspondent à une seule case de w0a : la valeur d'ordonnanceur de la cause 8 et l'enregistreur de jeu en arrière-plan de la cause 9. Les deux cases ne font que remettre un réglage à sa place, et sur une machine que personne n'a réglée, la première ne trouve rien à changer. Savoir si la saccade que tu ressens venait de l'une d'elles, seule une capture avant et après peut te le dire.

D'abord, détermine lequel des trois problèmes tu as

On les appelle du même mot et ils n'ont presque rien en commun.

• Des à-coups. La ligne de base est bonne et quelque chose de long se produit de temps en temps. C'est cette page.
• Une ligne de base irrégulière. Rien de dramatique, mais le jeu ne donne jamais une sensation de fluidité. C'est un problème de percentile : Moyenne de FPS élevée mais mauvais 1% low.
• Une chute. La fréquence d'images tombe et reste basse pendant des secondes ou des minutes. Des causes entièrement différentes : Chutes de FPS soudaines dans les jeux.

Obtiens un enregistrement avant de changer quoi que ce soit

C'est en devinant qu'on y passe des semaines. Une capture du jeu auquel tu joues vraiment, à l'endroit où il saccade vraiment, transforme « qu'est-ce que ça pourrait être » en « qu'est-ce qui s'est passé à ce pic » — et c'est l'« avant » auquel tout changement ultérieur sera comparé. Lire le benchmark explique comment.

Les causes, une par une

1. Un pilote qui retient un cœur de processeur

Tant qu'un pilote est à l'intérieur d'une interruption ou d'un appel de procédure différée, ce cœur s'exécute au-dessus de toutes les priorités de thread qui existent : il ne dessine rien et ne lit aucune entrée tant que le pilote n'a pas rendu la main. C'est une cause qui passe facilement inaperçue : elle n'apparaît dans aucun graphique de temps d'image et dans aucun gestionnaire de tâches.

Comment le savoir : mesure-le. La section noyau de Lire le test de latence liste chaque pilote qui a gardé un cœur, classé par plus long blocage, avec le nom du fichier. Au-delà d'environ 1 ms, un pilote déplace des rapports d'entrée ; à partir de 4 ms, la machine ne peut plus tenir un temps d'image stable, quoi que tu changes par ailleurs.

Ce que tu fais : mets à jour ce pilote-là chez le fabricant du matériel — pas tout le système, le fichier nommé. Les pilotes réseau, stockage et audio font partie des pilotes qui peuvent faire ça.

2. Des shaders qui compilent

Nouvel effet, nouvelle zone, nouvelle arme, et le jeu doit compiler un shader avant de pouvoir le dessiner. La compilation se fait sur le CPU pendant que l'image attend.

Comment le savoir : c'est pire dans les premières minutes d'une session ou d'une carte, ça s'estompe à mesure que tu joues, et ça revient après une mise à jour de pilote ou de jeu. Si ta saccade ne s'estompe pas, ce n'est pas ça — Saccades de compilation des shaders est la version longue.

Ce que tu fais : joue jusqu'à ce que ça passe, et ne fais pas de benchmark dans cette fenêtre ; tu mesurerais le compilateur.

3. Le disque depuis lequel le jeu charge en continu

Un jeu qui tire ses ressources à mesure que tu te déplaces saccade quand la lecture est lente, et l'image qui attend ces données est celle qui arrive en retard.

Comment le savoir : les à-coups coïncident avec l'entrée dans une nouvelle zone, et les longs intervalles d'image tombent dans la même fenêtre que l'activité disque. Vérifie l'évident : le jeu est-il sur un disque mécanique, le disque est-il presque plein, le dossier du jeu est-il dans un dossier synchronisé avec le cloud qui envoie chaque écriture, le fichier d'échange est-il sur un disque à plateaux. Un SSD pour un jeu qui charge en continu n'est pas un tweak, c'est la réponse.

4. La pression sur la mémoire

Quand la RAM se remplit, Windows déplace des pages vers le disque et les pages qui reviennent se ressentent comme des à-coups. Le cas moins évident, c'est la limite de validation : à mesure que la mémoire totale que Windows peut distribuer s'épuise, le gestionnaire de mémoire retire des pages aux programmes encore en cours d'exécution, et le jeu ressent ces retraits comme des gels de moins d'une seconde. Les deux s'améliorent dès l'instant où tu fermes un navigateur à quarante onglets.

5. Autre chose qui tourne

Le processus de travail de Windows Update, une tâche de maintenance, une analyse antivirus planifiée, un export vidéo que tu avais oublié. Ce travail ne s'arrête pas quand un jeu démarre ; il fait la queue pour le même cœur que le thread de rendu, donc il se manifeste par des pics de temps d'image plutôt que par une moyenne plus basse. Attendre que ça passe est une correction légitime.

Comment le savoir : une capture du benchmark garde ses plus longs intervalles de frame avec les accès disque et les hard faults tombés dans la même fenêtre. Quand c'étaient des processus de maintenance ou d'antivirus de Windows, la carte des longs intervalles compte ces intervalles et nomme les processus. C'est ce qui a coïncidé, pas la preuve que ce travail a retardé la frame : l'antivirus lit tout ce qu'ouvre n'importe quel programme.

6. La chaleur et les limites de puissance

Quand une puce atteint son plafond de température ou de puissance, la fréquence est tirée vers le bas puis remontée à répétition, et des temps d'image ondulants, c'est à quoi ça ressemble de l'intérieur. C'est le firmware qui prend cette décision lui-même, sans demander à Windows. Ça commence au bout d'un moment plutôt qu'immédiatement, et ça suit la température de la pièce.

7. L'écran

Un écran qui tourne en dessous de la fréquence de rafraîchissement qu'il prend en charge pose sous ta régularité d'images un plancher que le matériel n'impose pas. Vérifie la fréquence réelle au lieu de la supposer ; elle est fausse sur un nombre surprenant de machines après une installation neuve ou un changement de câble.

8. Une valeur d'ordonnanceur laissée par un vieil outil

Win32PrioritySeparation décide combien de temps un thread garde le processeur et combien de temps en plus reçoit l'application au premier plan. Les valeurs à quantums longs ou fixes, ou qui donnent au premier plan une part inférieure à 3:1, changent la façon dont le processeur est partagé entre le jeu et tout le reste ; on n'a pas mesuré ce que ça fait aux temps d'image. La carte Mémoire et valeurs système par défaut de la page Fix remet la valeur par défaut de Windows.

9. Les overlays et la couche de capture

Les overlays dessinent à l'intérieur de l'image du jeu lui-même, et un enregistreur en arrière-plan encode chaque image pour que les dernières minutes puissent être sauvegardées. Ferme-les un par un et teste, plutôt que tous d'un coup.

10. La partie, pas la machine

Un jeu en ligne peut partir en à-coups pour tout le monde sur le serveur en même temps. Si un contenu solo sur la même machine est propre et que l'enregistrement des temps d'image montre le jeu qui présente normalement, c'est une réponse réellement utile : ce n'est pas ton PC.

Les deux causes pour lesquelles w0a a une case

Cause 8 : « Garder la priorité du premier plan à la bonne valeur (Win32PrioritySeparation) » (page Optimisations)

Une valeur DWORD : Win32PrioritySeparation sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl.

La référence de Microsoft pour elle est une page archivée écrite pour Windows 2000 ; elle décrit six bits lus en trois paires, notés AABBCC :

• Valeur par défaut de Windows : 0x2 (binaire 000010). Sur une édition station de travail, cela veut dire des quantums plus courts et variables, le programme au premier plan recevant trois fois le temps de l'arrière-plan. La même référence donne 0x26 (100110 : plus court, variable, 3:1) pour le choix des options de performances qui favorise les programmes, et 0x18 (011000 : plus long, fixe, égal) pour celui qui favorise les services d'arrière-plan.
• Ce que fait la case : elle lit d'abord la valeur. Une valeur qui donne déjà au premier plan la part de 3:1, sans quantums plus longs et sans quantums fixes, est laissée exactement telle quelle, et la case le dit. Seule une valeur qui manque l'une de ces trois conditions est réécrite, à 0x26. Sur la valeur par défaut propre à Windows, la case n'écrit rien : sur une édition client, 0x2 ordonnance déjà comme le demande 0x26.
• Quand ça s'applique : après un redémarrage. Le noyau transforme cette valeur en sa table d'ordonnancement au démarrage, donc la modifier dans le registre ne change rien à l'ordonnanceur qui tourne déjà, et la case demande un redémarrage quand elle écrit.
• Retour en arrière : la carte Mémoire et valeurs système par défaut réécrit 2 et demande un redémarrage. Elle remet en même temps d'autres valeurs par défaut de la mémoire et de l'ordonnanceur.

Cause 9 : « Désactiver Xbox Game DVR » (page Optimisations)

Toutes sont des DWORD. Sur un processeur X3D à deux CCD, la case laisse la dernière valeur tranquille : la chaîne d'enregistrement est quand même coupée, mais la partie de Game Bar qu'écoute le pilote d'AMD continue de tourner. C'est une précaution, pas une cause prouvée, et le message de la case dit quel chemin elle a pris. Ryzen X3D, Game Bar et parking des cœurs explique pourquoi cette partie compte sur ces puces.

• Quand ça s'applique : w0a ne demande pas de redémarrage pour cette case.
• Ce à quoi tu renonces : l'enregistrement de Game Bar. Si Win+G ne s'ouvre plus ou si tu veux retrouver l'enregistrement, la carte Game Bar / capture de jeu réactive Game Bar et Game DVR avec les valeurs par défaut de Windows.
• Ce que dit le scan des saccades : il note, à titre d'information, quand GameDVR_Enabled ou AppCaptureEnabled est encore activé ; les deux valent 1 sur une installation propre, donc c'est la valeur par défaut, pas un défaut. Il lit aussi une troisième valeur, HistoricalCaptureEnabled (enregistrement en arrière-plan), mais seulement pour choisir sa formulation ; la case n'écrit pas cette valeur.

Vérifie toi-même

Ces commandes ne font que lire :

reg query "HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl" /v Win32PrioritySeparation
reg query "HKCU\System\GameConfigStore" /v GameDVR_Enabled
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\GameDVR"
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\GameDVR" /v AllowGameDVR
reg query "HKCU\Software\Microsoft\GameBar"

Comment lire les réponses :

• Les valeurs s'affichent en hexadécimal : Win32PrioritySeparation REG_DWORD 0x26 veut dire 0x26.
• 0x2 est la valeur par défaut de Windows et 0x26 est le choix de la référence qui favorise les programmes ; sur une édition client, les deux ordonnancent de la même façon. 0x18 est le choix qui favorise les services d'arrière-plan : des quantums plus longs et fixes, et aucune part en plus pour le premier plan, ce qui est exactement le sujet de la cause 8. Pour toute autre valeur, écris-la sur six chiffres binaires et lis-la avec le tableau ci-dessus.
• Pour Game DVR, 0x0 veut dire désactivé (la case) et 0x1 veut dire activé (la valeur par défaut de Windows).
• Si la requête sur AllowGameDVR se termine par une erreur au lieu d'une ligne, la valeur de stratégie n'existe pas, et c'est la valeur par défaut de Windows.

Ce que le scan fait de tout ça

Ce que cherche le scan des saccades exécute ces vérifications sur ce que Windows et tes pilotes ont déjà enregistré, et étiquette chaque constat comme prouvé, probable, candidat ou non vérifié. Deux choses à savoir : un scan qui trouve toujours dix problèmes est en train de te vendre les corrections, et une vérification qui n'a pas pu s'exécuter est comptée plutôt que traitée en silence comme propre.

Ensuite change une seule chose et capture à nouveau la même scène. Cinq changements et une mesure ne t'apprennent rien sur celui qui comptait, et tout ce qui n'a pas fait bouger un chiffre doit être annulé.

Ce qui n'est pas la cause

Tout cela circule sans fin comme correction des saccades, et w0a refuse d'écrire chacune de ces valeurs, pour des raisons consignées :

• DisablePagingExecutive, LargeSystemCache et DisablePageCombining modifient le gestionnaire de mémoire du noyau ; NtfsMemoryUsage modifie le pool du pilote NTFS ; IoPageLockLimit et SecondLevelDataCache sont elles aussi des suppositions du noyau. Les valeurs au niveau du noyau relèvent d'une règle du produit : elles ne sont jamais écrites.
• GlobalTimerResolutionRequests se trouve sous Session Manager\kernel, une clé que le produit refuse purement et simplement.
• MSISupported change le mode d'interruption d'un périphérique ; mal réglé, le résultat peut être un écran noir.
• FeatureSettingsOverride et FeatureSettingsOverrideMask désactivent les protections contre Spectre et Meltdown.
• OverlayTestMode et DisableOverlays désactivent la superposition multiplan (MPO). Sur une vraie machine sous Windows 11 25H2, elles ont figé CS2 net, de façon reproductible.
• TdrDelay et TdrDdiDelay allongent le watchdog du pilote graphique, ce qui ne fait que rendre chaque gel plus long ; TdrLevel désactive la récupération.

Sur une machine qui ne manque pas de mémoire, un nettoyeur de mémoire ne change rien de mesurable.

À lire aussi

• Chutes de FPS soudaines dans les jeux
• Saccades de compilation des shaders
• Lire le test de latence
• Ce que cherche le scan des saccades
• Moyenne de FPS élevée mais mauvais 1% low
• Latence DPC : quand c'est le pilote qui saccade
• Annuler ce que w0a a changé