Un compteur peut afficher 90 ou 120 images par seconde et le jeu donner malgré tout une impression de saccade. La moyenne reste élevée, mais une image met soudain beaucoup plus longtemps que les autres à arriver. Parmi les causes possibles, la compilation des shaders est devenue l’une des plus visibles sur PC. Elle n’explique cependant pas tous les ralentissements, et vider des caches au hasard peut parfois aggraver la situation.
Pour comprendre le problème, il faut regarder le frametime, c’est-à-dire le temps nécessaire pour produire chaque image, plutôt que la seule moyenne de FPS. Le guide BlackFury sur les FPS moyens, les 1 % low et la fluidité réelle montre pourquoi quelques pics peuvent être perceptibles même quand la moyenne paraît excellente.
Un shader, qu’est-ce que c’est ?
Un shader est un programme exécuté par le processeur graphique. Il participe notamment au calcul des matériaux, de l’éclairage, des ombres ou de certains effets. Le code fourni par le jeu doit être transformé en instructions adaptées à l’API, au pilote et au GPU utilisés. Dans un jeu moderne, le nombre de combinaisons peut devenir très important.
Avec Direct3D 12, une grande partie de l’état graphique est regroupée dans des objets appelés Pipeline State Objects, ou PSO. Microsoft explique que ces objets associent notamment les shaders, les formats, le rasterizer, le blend et le depth-stencil. Ils sont conçus pour permettre au matériel de préparer ces dépendances en amont et de basculer rapidement entre des états déjà créés. La documentation Direct3D 12 sur l’état du pipeline détaille ce fonctionnement.
Pourquoi la compilation peut provoquer une saccade
Si le jeu ou le pilote doit compiler un shader ou construire un pipeline au moment exact où un nouvel effet apparaît, le travail peut retarder l’image courante. La moyenne calculée sur plusieurs secondes masque alors le problème, tandis que la courbe de frametime montre un pic. Le joueur le ressent comme un bref arrêt, parfois lors de la première explosion, de l’arrivée dans une nouvelle zone ou de l’apparition d’un matériau inédit.
Khronos rappelle, dans son guide officiel consacré au cache de pipelines Vulkan, que la création d’un pipeline peut être coûteuse parce qu’elle comprend notamment la compilation des shaders. Un cache permet de réutiliser des pipelines déjà créés et d’éviter une partie de ce travail lors des exécutions suivantes.
Précompilation, compilation en arrière-plan et compilation à la volée
Les jeux ne gèrent pas tous cette étape de la même manière. Certains affichent une phase de préparation au premier lancement. D’autres compilent progressivement en arrière-plan. D’autres encore découvrent des combinaisons pendant la partie. Ces choix dépendent du moteur, de l’API, du nombre de variantes et de la stratégie du studio.
La précompilation rallonge l’attente avant de jouer, mais peut réduire les pics ensuite. La compilation en arrière-plan cherche un compromis, au risque de concurrencer le jeu sur le processeur. La compilation à la demande évite un long écran initial, mais peut rendre les premières minutes ou la découverte d’une zone moins fluides.
À quoi sert le cache de shaders ?
Le cache conserve le résultat d’une compilation pour pouvoir le réutiliser. NVIDIA indique dans l’aide de son panneau de configuration que la compilation des shaders est une cause fréquente de saccades et que le cache évite de répéter ce travail lors des lancements suivants. Le constructeur précise également qu’une installation de pilote peut supprimer le cache, ce qui explique pourquoi un jeu peut saccader davantage juste après une mise à jour. Voir l’aide officielle NVIDIA sur le cache de shaders.
Un cache n’est pas universel. Les données peuvent dépendre du jeu, du pilote, du GPU et de la version des shaders. Le standard Vulkan prévoit d’ailleurs des informations permettant de détecter une incompatibilité avec le périphérique ou la version du pilote. Un cache devenu incompatible doit être reconstruit ; ce n’est pas forcément le signe d’une panne.
Pourquoi vider le cache n’est pas un remède systématique
Supprimer un cache corrompu peut résoudre un cas précis, mais le faire régulièrement oblige le système à recompiler ce qu’il avait déjà préparé. On peut donc transformer une petite anomalie en saccades répétées au prochain lancement. Je déconseille les nettoyages automatiques agressifs qui effacent les caches graphiques sans diagnostic.
La bonne question n’est pas « comment vider tous les caches ? », mais « le problème a-t-il commencé après un changement identifiable ? ». Une mise à jour du jeu, du pilote, un remplacement de carte graphique ou une corruption après un arrêt brutal constitue un contexte plausible. En dehors de ces situations, il vaut mieux mesurer avant d’effacer.
Reconnaître une saccade de compilation
Aucun symptôme isolé ne donne une certitude absolue, mais plusieurs indices se recoupent souvent :
- le pic apparaît la première fois qu’un effet ou une zone est affiché ;
- le même passage devient plus fluide lors d’un second essai ;
- le problème est plus marqué après une mise à jour du pilote ou du jeu ;
- le GPU n’est pas forcément saturé au moment du pic ;
- la courbe de frametime montre une pointe brève plutôt qu’une baisse continue.
À l’inverse, une baisse persistante dans une zone lourde, une VRAM constamment saturée ou des accès disque continus orientent vers d’autres causes.
Ne pas confondre shaders, traversal stutter et manque de mémoire
Le traversal stutter apparaît lorsque le jeu charge ou décompresse des données en parcourant le monde. Il peut se produire à chaque franchissement d’une limite, même si les shaders sont déjà compilés. Une saturation de VRAM peut provoquer des transferts et des chutes plus durables. Un processeur débordé par la simulation ou un processus en arrière-plan produit encore un autre profil.
C’est pour cela qu’un diagnostic sérieux combine la courbe de frametime, l’utilisation CPU et GPU, la mémoire vidéo, les accès au stockage et la répétabilité du phénomène. Le dossier BlackFury sur le coût réel d’un PC gamer rappelle qu’un remplacement de composant ne doit pas être décidé sur un seul chiffre.
La méthode pratique avant de modifier quoi que ce soit
- Laisser finir la préparation. Si le jeu affiche une compilation ou une optimisation, attendre sa fin avant de lancer une partie.
- Redémarrer une fois le jeu. Cela permet de comparer un premier passage avec un cache froid et un second passage.
- Observer le frametime. Une courbe est plus utile qu’un compteur de FPS moyen.
- Noter le contexte. Mise à jour récente, nouvelle zone, changement de pilote, paramètres modifiés.
- Vérifier l’espace libre. Un disque presque plein peut gêner la création ou l’entretien des caches.
- Éviter les nettoyeurs automatiques. Ne supprimer un cache qu’après avoir identifié une raison plausible.
- Comparer les paramètres. Le ray tracing et certains effets multiplient parfois les variantes à préparer.
- Tester une version stable du pilote. Une mise à jour n’est utile que si elle corrige un problème connu ou apporte le support du jeu.
Faut-il augmenter la taille du cache dans le pilote ?
Une limite trop petite peut forcer l’éviction de données encore utiles, surtout si plusieurs jeux lourds partagent le même disque. Une valeur plus généreuse peut aider, à condition d’avoir suffisamment d’espace. Elle ne corrigera cependant pas un jeu qui compile ses pipelines au mauvais moment ou qui ne réutilise pas correctement le cache.
Je conseille de rester mesuré : vérifier d’abord l’espace disponible et la valeur actuelle, puis changer un seul réglage à la fois. Une option « illimitée » n’est pas automatiquement meilleure sur un petit SSD. L’objectif est d’éviter les évictions inutiles sans laisser le stockage se remplir silencieusement.
Après une mise à jour de pilote
Le premier lancement peut être moins fluide parce que certaines données doivent être reconstruites. Il est raisonnable de laisser le jeu terminer sa phase de préparation et de refaire un parcours comparable avant de conclure que le nouveau pilote est moins performant. Si les saccades se répètent exactement de la même façon après plusieurs passages, la compilation n’est probablement pas la seule explication.
NVIDIA a également présenté en 2026 une fonction de compilation automatique des shaders pour certaines configurations et certains pilotes récents. Cette évolution montre que le problème est pris au sérieux, mais elle ne dispense pas les développeurs de préparer correctement leurs pipelines et ne couvre pas tous les jeux ni tous les GPU. Il faut vérifier la compatibilité officielle avant d’en attendre un bénéfice.
Ce que le joueur peut réellement améliorer
Le joueur ne peut pas réparer l’architecture d’un moteur. Il peut en revanche éviter d’aggraver le problème, fournir des mesures utiles et distinguer une première exécution imparfaite d’un défaut répétitif. Lorsque le jeu propose un outil de précompilation, il faut le laisser travailler. Lorsqu’un bug persiste, une capture de frametime, la version du pilote et un scénario reproductible aideront davantage qu’un simple « ça rame ».
Pour une nouvelle installation ou une réinstallation de Windows, le guide BlackFury sur l’inventaire des sauvegardes de jeux permet aussi de préparer proprement les données importantes avant de toucher au système.
La checklist BlackFury
- Attendre la fin de toute précompilation annoncée.
- Comparer premier et second passage dans la même zone.
- Observer le frametime et les 1 % low.
- Noter la version du jeu et du pilote.
- Vérifier VRAM, CPU et accès disque.
- Conserver de l’espace libre pour les caches.
- Ne pas vider les caches sans raison précise.
- Changer un seul paramètre à la fois.
- Signaler un scénario reproductible au studio.
Conclusion : une moyenne de FPS ne raconte pas toute l’histoire
La compilation des shaders illustre parfaitement la limite des moyennes. Un PC peut produire beaucoup d’images et trébucher au mauvais moment. Les caches, la précompilation et une bonne gestion des pipelines réduisent le problème, mais leur efficacité dépend largement du jeu et du pilote. Côté joueur, la meilleure approche reste de mesurer, de comparer et d’éviter les recettes de nettoyage appliquées sans diagnostic.
