Saccades de compilation des shaders : pourquoi les premières minutes sont les pires

Tu relances un jeu auquel tu n'as pas touché depuis un moment et les dix premières minutes sont affreuses. Chaque nouvelle arme, chaque nouvel effet, la première apparition d'un ennemi particulier — un à-coup. Puis ça se tasse, et dès la deuxième soirée le jeu est fluide. Rien de ce que tu as changé n'y est pour quelque chose. C'est le temps.

Ou l'autre version : le jeu allait bien, tu as mis à jour le pilote graphique, et toute la première heure est de nouveau difficile.

Les deux relèvent du même mécanisme, et c'est l'une des rares causes de saccade qui soit réellement normale, au sens où une machine en bonne santé qui fait tourner un logiciel correct la produit.

Pourquoi ce travail doit se faire sur ta machine

Un shader est un petit programme qui tourne sur le GPU. Le développeur du jeu l'écrit dans un langage de haut niveau et le compile, mais seulement à moitié — vers une forme intermédiaire qui décrit ce que fait le programme, pas comment telle ou telle puce graphique doit le faire.

Le code machine que ton GPU exécute vraiment ne peut pas être produit à l'avance, parce qu'il dépend de deux choses que le développeur n'a pas : l'architecture exacte de ton GPU, et la version exacte de ton pilote. C'est le compilateur du pilote lui-même qui transforme la forme intermédiaire en instructions pour le silicium de ta machine, et cette compilation se fait sur ton CPU, au moment où le jeu a besoin du shader.

Donc la première fois qu'une scène a besoin d'une combinaison précise de shader, d'état de rendu et de format de sommets, il faut compiler quelque chose. Si le jeu le demande au milieu d'une image et attend, cette image est en retard. Cette image en retard, c'est l'à-coup que tu as senti.

Le résultat est écrit dans un cache de shaders sur le disque. La deuxième fois que la même chose apparaît, le code compilé est lu dans le cache au lieu d'être reconstruit, et c'est exactement pour ça que le jeu s'améliore à mesure que tu joues et que la deuxième session se passe bien.

Ce qui te renvoie au point de départ

Le cache n'est valable que pour le pilote et le matériel qui l'ont construit. Tout ce qui suit l'invalide, en tout ou en partie, et la première heure de jeu redevient difficile :

Une mise à jour du pilote graphique. Nouveau compilateur, nouvelle sortie ; les anciennes entrées ne sont plus fiables, donc elles disparaissent.
Une mise à jour du jeu. Des shaders modifiés sont des shaders neufs.
Une autre carte graphique, y compris le fait de changer la carte sur laquelle un jeu tourne.
Un outil de nettoyage qui le supprime. Le nettoyage de disque de Windows lui-même liste le cache de shaders DirectX parmi les catégories de fichiers temporaires qu'il peut retirer, et les nettoyeurs tiers l'emportent régulièrement aussi. Assistant Stockage est le réglage Windows qui lance ce nettoyage à intervalles réguliers, donc ça vaut le coup de vérifier quelles catégories tu l'as autorisé à supprimer.
Le cache qui atteint sa limite de taille et évince les entrées les plus anciennes pour faire de la place.

Rien de tout ça n'est un défaut. C'est le prix d'un cache juste plutôt que périmé.

Comment savoir que c'est bien ça

La compilation des shaders a une signature reconnaissable, et elle ne ressemble à rien d'autre dans la liste des saccades :

Ça s'estompe. C'est le signe distinctif. Si ta saccade est la même à la troisième heure qu'à la troisième minute, ce n'est pas ça.
C'est lié à la nouveauté. Première vue d'une arme, d'une zone, d'un effet météo, d'un ennemi particulier. Parcourir le même couloir une deuxième fois est propre.
Ça ignore la température et la durée de session. Les problèmes thermiques empirent à mesure que tu joues ; ça, ça s'améliore.
Ça revient à un moment que tu peux nommer — après une mise à jour de pilote, après un correctif, après un nettoyage — plutôt qu'au hasard.
Ce n'est pas le GPU qui est occupé. La compilation, c'est du travail processeur. Un GPU qui reste bien en dessous de la pleine occupation pendant ces à-coups est attendu ici, et ce n'est pas la preuve du problème distinct décrit dans Chutes de FPS soudaines dans les jeux.

Si ces cinq points ne décrivent pas ton symptôme, reviens à la liste générale de pourquoi les jeux saccadent sous Windows 11 — les causes qu'on y trouve ne s'estompent pas d'elles-mêmes.

Que faire

L'essentiel : laisse faire. Mais il y a de vrais choix sur les bords.

Ne supprime pas le cache de shaders en guise de correction. C'est le seul conseil de cette page qui mérite d'être lu deux fois. Vider le cache est prescrit sans arrêt comme remède aux saccades, et ce que ça fait en réalité, c'est te garantir de repayer tout le coût de compilation depuis zéro. C'est une étape de dépannage légitime en cas de corruption visuelle après un changement de pilote. C'est le contraire d'une correction de performance.

Utilise l'étape de précompilation du jeu s'il en propose une, et ne la saute pas. Un jeu qui passe deux minutes sur un écran « compilation des shaders » avant le menu fait exactement ce travail à l'avance, là où il ne te coûte que de l'attente.

Laisse la machine allumée un moment après une mise à jour de pilote. Certains pilotes reconstruisent les shaders DirectX 12 pendant que le système est au repos, précisément pour que le runtime en fasse moins plus tard. Ça n'aide que si la machine a droit à ce temps de repos.

Garde le jeu et son cache sur un SSD, et hors d'un dossier synchronisé. Un client cloud surveille chaque écriture, et un jeu écrit son cache de shaders en permanence — chaque entrée devient du travail de pilote de filtre plus un envoi sur la connexion que ta partie est en train d'utiliser.

Ne mesure pas à l'intérieur de cette fenêtre. Une capture prise dans les premières minutes qui suivent une mise à jour de pilote mesure le compilateur, pas le pilote. Lire le benchmark couvre les règles de comparaison ; c'est une façon facile d'enfreindre la première sans le vouloir.

Ce que le scan en dit

Le scan des saccades vérifie si un cache de shaders a été vidé récemment, et quand il en trouve un il dit ce que dit cette page : le jeu recompile le cache supprimé pendant que tu joues, une saccade en début de session est normale et s'estompe d'elle-même, et il ne faut pas faire de benchmark tant que cette fenêtre n'est pas passée.

Ce n'est délibérément pas présenté comme un défaut à réparer. Il n'y a rien à réparer — il y a un coût à payer une fois, et la chose honnête qu'un outil peut faire, c'est te dire que tu es dedans pour que tu ne passes pas la soirée à accuser un réglage.

Là où ça cesse d'être normal

Une saccade de compilation qui ne s'estompe jamais est un autre problème : le cache n'est pas conservé. Vérifie que le disque n'est pas plein, que le cache n'est pas effacé par un nettoyage planifié entre deux sessions, et que le dossier du jeu n'est pas à un endroit qu'un client cloud ou une limite de taille vide sans arrêt.

Et si le run est irrégulier d'un bout à l'autre plutôt que concentré au début, c'est plutôt Moyenne de FPS élevée mais mauvais 1% low que tu regardes, qui est un problème d'événement et non de mise en chauffe.