Monster Hunter Wilds PC : isoler une régression de FPS après Title Update 2

Une régression de FPS ne se prouve pas avec un seul compteur

Une baisse de 15 ou 20 FPS ressentie dans Monster Hunter Wilds après Title Update 2 peut venir du patch, mais aussi d’un cache shader reconstruit de travers, d’un pilote GPU changé entre-temps, d’un overlay resté actif ou d’un profil d’overclock devenu instable. Modifier cinq réglages dans le menu graphique puis conclure que « le jeu est cassé » ne permet d’isoler aucune cause.

Le protocole utile repose sur une règle sèche : un seul changement entre deux runs comparables. La machine, la zone, la durée, la résolution et les paramètres restants doivent rester identiques. À la fin, le journal permet de décider rationnellement entre trois actions : attendre un correctif, revenir à un pilote déjà validé, ou conserver un réglage temporaire qui stabilise le jeu.

La configuration de référence à figer avant le premier test

Élément à documenter	Valeur à figer pour le run de base	Pourquoi cette donnée compte
Version du jeu	Version exacte de Monster Hunter Wilds et date du patch	Évite de comparer deux exécutables différents.
Pilote GPU	Numéro de version complet	Un rollback n’a de sens que face à une version précise déjà testée.
Affichage	Résolution, mode plein écran ou fenêtré sans bordure, V-Sync, limiteur FPS et VRR	Le comportement du frame pacing varie selon cette combinaison.
Upscaling	DLSS ou FSR, mode choisi, Frame Generation et Reflex	Ces fonctions doivent être activées séparément, jamais en bloc.
Réglages lourds	Qualité de mesh, ombres, brouillard volumétrique et distance de tirage	Ils deviennent essentiels lorsque la VRAM est proche de sa limite pratique.
État système	Mode d’alimentation Windows, overclock CPU/GPU/RAM, logiciels ouverts	Une fréquence GPU ou CPU différente invalide facilement la comparaison.
Outils tiers	Overlays, capture vidéo, Reshade, mods et injecteurs	Ils ajoutent des variables au rendu et à la composition de l’image.

Le run de référence doit utiliser une installation temporairement propre : Steam Overlay, Discord Overlay, Xbox Game Bar, overlay du pilote graphique, RTSS, MSI Afterburner en surimpression, outils de capture, Reshade, mods et injecteurs coupés. Les profils d’overclock GPU, CPU et RAM doivent aussi être retirés pour ce point de départ. Cette préparation prend généralement 10 à 15 minutes ; elle évite de perdre une soirée à comparer des mesures qui ne décrivent pas le même système.

Le cache shader : traiter le premier suspect avant les réglages graphiques

Après une mise à jour du jeu, un changement de pilote ou l’utilisation du benchmark, le fichier shader.cache2 mérite d’être remis à zéro. Fermez le jeu, supprimez ce fichier dans le dossier d’installation, puis supprimez également le cache associé au benchmark s’il a été utilisé. Au redémarrage, laissez la reconstruction des shaders se terminer avant toute mesure.

Un cache neuf et un cache déjà chaud ne sont pas deux états directement comparables. Le premier passage peut subir des à-coups de compilation, puis se stabiliser. Il faut donc effectuer un passage de chauffe, ne pas le compter, puis mesurer le même trajet au moins trois fois. Une baisse qui n’apparaît que sur le premier parcours après nettoyage n’est pas une régression de performance établie.

Construire un benchmark reproductible, dans le jeu et hors du jeu

Le benchmark officiel de Monster Hunter Wilds fournit une référence utile si les mêmes réglages et la même version de pilote sont conservés. Son score classe la machine de « Excellent » à « Difficulté à jouer », avec le palier « Excellent » à partir de 20 000 points et le palier « Jouable » entre 10 250 et 12 999 points. Ce score sert de contrôle global ; il ne remplace pas un trajet dans une zone où la baisse de fluidité est réellement observée.

Pour le test en jeu, fixez un point de départ, une direction de caméra et un trajet de 60 à 120 secondes. Reproduisez exactement le même déplacement : sortie de hub, traversée d’une zone précise ou séquence de combat identique si elle est disponible. Les mesures prises dans un lobby prolongé, dans une zone chargée ou au cours d’un simple déplacement ne doivent pas être mélangées dans la même colonne.

Mesure	À relever à chaque run	Lecture utile
FPS moyen	Valeur sur le même parcours	Indique la tendance générale, sans décrire seul les micro-saccades.
1 % low	Valeur minimale représentative	Révèle les chutes de fluidité qui disparaissent derrière une moyenne correcte.
0,1 % low	Si l’outil de mesure le permet	Permet d’identifier les à-coups les plus sévères.
Frametimes	Courbe ou relevé pendant le trajet	Montre les pics irréguliers, y compris lorsque le FPS moyen bouge peu.
Utilisation GPU, CPU et VRAM	Valeurs pendant la même scène	Relie les chutes de fluidité à la charge observée, sans tirer de diagnostic hâtif.
Températures et fréquences GPU	Valeurs maximales et comportement sur la durée	Vérifie qu’un run ne s’est pas déroulé avec des fréquences différentes.

Un résultat ne devient exploitable que s’il se répète dans le même sens sur les trois passages de mesure. Une seule chute isolée ne justifie ni une réinstallation, ni un rollback de pilote.

La séquence DLSS, FSR et Frame Generation à respecter

DLSS, FSR et la Frame Generation peuvent améliorer le débit affiché tout en modifiant le frame pacing. Ils doivent donc être testés séparément. Revenir au profil de base après chaque run évite qu’un résultat soit contaminé par le réglage précédent.

Run	Upscaling	Frame Generation	Objectif du test
A	Désactivé	Désactivée	Établir le rendu de référence sans mécanisme d’interpolation.
B	DLSS ou FSR activé	Désactivée	Mesurer l’effet de l’upscaling seul.
C	DLSS ou FSR activé	Activée	Vérifier le gain affiché et la stabilité des frametimes.
D	Désactivé	Activée, si le jeu l’autorise	Isoler la Frame Generation de l’upscaling.

Si le run B est stable et que le run C dégrade les 1 % low ou introduit des frametimes irréguliers, la Frame Generation est la variable fautive dans cette configuration. Le contournement temporaire consiste alors à conserver l’upscaling sans Frame Generation, plutôt qu’à réduire indistinctement tous les paramètres graphiques.

Tester le limiteur FPS, la V-Sync et le VRR sans mélanger les effets

La combinaison la plus lisible pour diagnostiquer une baisse reste un réglage défini : V-Sync désactivée, limiteur FPS choisi et VRR activé ou désactivé selon le run. Le piège classique consiste à modifier les trois en même temps. Une amélioration devient alors impossible à attribuer à une fonction précise.

• Commencez avec V-Sync désactivée, VRR désactivé et une limite de FPS fixe.
• Relancez exactement le même trajet avec le VRR activé, sans toucher au limiteur.
• Revenez à l’état initial, puis comparez limiteur fixe et fréquence d’images débridée.
• Testez la V-Sync en dernier, seule, si le comportement reste instable.

Un limiteur modéré, atteignable dans la scène de test, peut fournir une expérience plus régulière qu’un débit totalement débridé. Cette mesure est un contournement de stabilité ; elle ne corrige pas une perte de performances confirmée après une mise à jour.

Pilotes GPU et VRAM : séparer la cause du symptôme

Le test de pilote ne doit intervenir qu’après le cache shader, les overlays, les mods et l’overclock. Installez une version de pilote précédemment stable, reprenez le profil de base exact, puis effectuez les mêmes trois passages. Si la baisse disparaît uniquement avec cette version, le rollback est justifié tant qu’un pilote plus récent ne reproduit pas le résultat.

La VRAM exige une lecture tout aussi méthodique. Une utilisation mémoire qui augmente pendant le trajet, accompagnée d’une chute des 1 % low, justifie un second test avec un seul réglage lourd réduit : qualité de mesh, ombres, brouillard volumétrique ou distance de tirage. Chaque paramètre doit être modifié séparément. Réduire toute la qualité graphique d’un coup peut masquer le déclencheur réel et produire une image dégradée sans résoudre les frametimes.

Verdict : garder uniquement le correctif qui survit au test

La bonne décision dépend du premier changement qui reproduit clairement l’écart. Un cache shader reconstruit qui restaure les 1 % low ne demande pas de rollback. Une version de pilote qui retrouve le niveau de référence justifie un retour temporaire vers ce pilote. Une Frame Generation, un overlay ou un profil d’overclock qui dégrade le run doit rester désactivé jusqu’à nouvel essai.

Si les mesures propres restent inférieures à un journal conservé avant Title Update 2, avec le même pilote, les mêmes réglages et aucune couche tierce active, conserver ces données est préférable à une succession de tweaks. Le dossier doit contenir les captures des réglages, la version du pilote, l’état du cache shader, une vidéo du trajet de test et les relevés de FPS moyen, 1 % low, frametimes, VRAM et fréquences GPU.