Vous connaissez la scène : vous passez les textures en Ultra parce que le menu déroulant suggère que vous achetez « plus de jeu », puis le graphe des temps de trame devient de l’art moderne. Le GPU n’est pas saturé, le CPU non plus, et pourtant votre panoramique de caméra ressemble à traîner un canapé sur de la moquette.
Ce n’est généralement pas une « mauvaise optimisation » au sens abstrait. C’est une situation très spécifique : pression sur la VRAM, résidence des textures, et la vilaine interaction entre ce que le moteur veut, ce que le pilote rapporte et ce que votre carte peut réellement garder en mémoire sans paginer.
« Ultra » est une politique, pas une promesse
« Ultra » n’est pas une unité universelle. Ce n’est pas le « meilleur ». Ce n’est pas « correct ». C’est un ensemble de choix faits par un studio sous contrainte de temps, avec une connaissance incomplète de votre machine, de vos applications en arrière-plan, de la version du pilote et de votre tolérance aux saccades.
La qualité des textures est l’endroit le plus facile où « Ultra » peut devenir absurde, car c’est le réglage qui peut silencieusement exiger le plus de VRAM tout en apportant la moindre amélioration visible. Beaucoup de moteurs s’allouent volontiers dans un coin, puis passent votre budget de frame time à faire du triage mémoire.
Voici le modèle mental que j’utilise en production et dans les jeux : quand vous êtes près d’une limite de capacité, tout devient un problème d’ordonnancement. Ce n’est pas juste « est-ce que je suis à court de VRAM ? » C’est « à quelle fréquence est-ce que je force des évictions, des uploads et de la décompression aux pires moments possibles ? »
Ce que vous devriez faire, par défaut
- Commencez par les textures en High, pas Ultra, même sur un GPU puissant. Ensuite mesurez. Si vous ne voyez pas la différence en mouvement, ne la payez pas en saccades.
- Gardez une marge de sécurité VRAM. Si votre overlay indique 95–100 % de VRAM dans une scène chargée, vous n’« utilisez pas tout efficacement ». Vous flirtez avec le paging.
- Privilégiez des temps de trame stables plutôt que le pic de FPS. Ce sont les pics que vos mains ressentent.
Une citation qui devrait être collée près de chaque bascule « Ultra » : « L’espoir n’est pas une stratégie. »
— Gene Kranz
Textures, VRAM, et pourquoi ça devient étrange
Les textures sont grosses, nombreuses, et pas toutes égales. Un curseur « qualité des textures » change généralement un mélange de :
- Résolution maximale des textures (par ex., 2K → 4K)
- Biais de mip et règles de résidence (à quel point on utilise/garde les mips inférieurs)
- Paramètres par défaut de filtrage anisotrope (parfois séparé, parfois inclus)
- Taille du pool de streaming (combien de mémoire le moteur réserve pour le streaming)
- Choix de formats de compression pour certaines classes d’assets (très variable)
La VRAM n’est pas un seul « seau ». C’est une hiérarchie : mémoire vidéo locale, plus mémoire partagée/système, plus ce que l’OS/le pilote peut paginer. Les API modernes (DX12/Vulkan) exposent le budgeting et la résidence plus explicitement, mais l’expérience dépend toujours du pilote et du moteur qui se comportent de manière responsable.
Calculs de textures qui rendent « Ultra » coûteux
Une surprise courante : une seule texture 4K n’est pas « quelques mégaoctets ». Cela dépend du format et des mipmaps. Approximativement :
- RGBA8 non compressé 4K : 4096×4096×4 octets ≈ 64 Mio pour le mip supérieur, plus ~33 % pour la chaîne de mips → ~85 Mio.
- BC7 compressé 4K : ~16 Mio pour le mip supérieur, plus la chaîne de mips → ~21 Mio.
Maintenant multipliez par : albedo + normal + roughness/metalness/AO + emissive + masques. Puis multipliez par le nombre de matériaux uniques à l’écran, plus les assets « au cas où » que le moteur garde parce qu’il doit prédire où vous tournerez ensuite. La facture arrive vite.
Petite blague n°1 : Les textures Ultra, c’est comme emmener un réfrigérateur pleine taille à un pique-nique. Techniquement impressionnant ; socialement discutable.
La résolution n’est pas le même réglage
La résolution d’écran affecte principalement les render targets (couleur, profondeur, buffers de post-traitement) et le coût de shading. La qualité des textures affecte surtout la résidence des assets. Vous pouvez jouer en 4K avec des textures High sans problème, et jouer en 1080p avec des textures Ultra et avoir un désastre saccadé. Ce sont des points de pression différents.
Faits et contexte à partager en soirée (ou en post-mortem)
- Le mipmapping est plus vieux que la plupart des GPU que vous avez possédés. Il a été décrit au début des années 1980 pour réduire l’aliasing et améliorer le comportement du cache, et il reste un outil central pour la stabilité.
- Les consoles ont normalisé des budgets mémoire fixes. L’ère du « 8 Gio de mémoire unifiée » a forcé les studios à être disciplinés sur la résidence et le streaming, même si les ports PC oublient parfois cette leçon.
- DX11 cachait beaucoup de douleurs de résidence. La gestion mémoire par le pilote simplifiait la vie, jusqu’à ce que ce ne soit plus le cas ; DX12/Vulkan l’ont rendu explicite, ce qui est excellent pour la performance et terrible pour les budgets bâclés.
- La compression de textures est une stratégie de bande passante, pas seulement de stockage. Les formats de compression par bloc (BCn/ASTC) réduisent l’empreinte VRAM et le trafic mémoire ; c’est une fonction de performance.
- Les normal maps dominent souvent plus que les albedos. On pense « textures de couleur », mais les normals haute fréquence sont partout, et rarement bon marché.
- Le texturing virtuel (« mega textures ») n’est pas nouveau. Des variantes existaient depuis des années, mais les SSD modernes et de meilleures tables de pages GPU l’ont rendu pratique à grande échelle.
- Le reporting de la VRAM n’est pas standardisé entre les outils. « Allocated », « committed », « resident » et « in use » sont des états différents ; les overlays les mélangent souvent.
- Resizable BAR peut changer la sensation d’oversubscription. Cela n’augmente pas la VRAM, mais peut influencer le comportement de transfert et réduire certains pires blocages.
- La bande passante PCIe n’est pas la bande passante VRAM. Quand vous paginez des textures depuis la mémoire système, vous quittez une autoroute multi-centaines de Gio/s pour une route beaucoup plus étroite avec des feux.
Que se passe-t-il réellement quand on « manque de VRAM »
La plupart du temps, rien de dramatique. Pas de crash. Pas d’erreur. Juste des temps de trame incohérents.
Sous pression VRAM, le système jongle avec :
- Évictions : pousser des ressources hors de la VRAM locale pour faire de la place.
- Uploads : rapatrier des textures quand elles sont nécessaires.
- Agitation d’état : changer quels mips sont résidents, parfois plusieurs fois par seconde.
- Synchronisation : attendre la fin des transferts, des fences ou des queues de copie.
Le mode d’échec n’est pas « faible FPS moyen ». C’est des saccades lors de la rotation de la caméra, des à-coups en entrant dans une nouvelle zone, ou des pics périodiques toutes les quelques secondes. Ceux-ci se corrèlent avec des événements de streaming, la compilation de shaders, ou la collecte de déchets aussi — mais la pression VRAM amplifie tout parce que tout se bat pour le même pool de résidence limité.
Surconsommation de VRAM : la taxe cachée
Quand le « budget » d’un moteur dépasse la VRAM locale, il peut quand même fonctionner en s’appuyant sur la mémoire système (ou pire, le fichier d’échange). C’est l’oversubscription. Pensez-y comme lancer une base de données avec un cache tampon plus grand que la RAM : techniquement ça démarre, puis ça passe sa vie à thrasher.
Si vous ne retenez qu’un point actionnable de cet article : gardez votre jeu de travail confortablement à l’intérieur de la VRAM. « Confortablement » signifie laisser de la place pour les pics, l’overhead du pilote, et ce que le moteur ne vous a pas dit qu’il fait.
Petite blague n°2 : Passer les textures en Ultra sur une carte à VRAM limitée est une excellente façon d’expérimenter des « écrans de chargement immersifs » en temps réel.
Guide de diagnostic rapide
Ceci est l’ordre qui trouve le goulot d’étranglement rapidement sans transformer votre soirée en danse interprétative de réglages.
Première étape : prouver s’il s’agit de pression VRAM
- Activez un overlay VRAM (overlay du pilote ou in-game si fiable) et reproduisez la saccade dans la scène exacte qui pose problème.
- Surveillez le fait que la VRAM soit saturée (95–100 %) et les pics des temps de trame coïncidant avec le mouvement de la caméra ou des transitions riches en assets.
- Baissez la qualité des textures d’un cran (Ultra → High). Ne changez rien d’autre pour l’instant. Si les pics diminuent sensiblement, vous avez trouvé votre levier.
Deuxième étape : séparer la VRAM des autres causes de saccades
- Vérifiez la saturation CPU par cœur. Un seul cœur saturé peut provoquer des stalls de streaming et de draw-call qui ressemblent à des problèmes de VRAM.
- Vérifiez les symptômes de compilation de shaders : des pics qui apparaissent la première fois qu’un effet est vu, puis disparaissent.
- Vérifiez les I/O de stockage : si votre disque est à 100 % d’activité lors du streaming, vos textures arrivent en retard quelle que soit la VRAM.
Troisième étape : optimiser pour la cohérence
- Réglez les textures au niveau le plus élevé qui reste dans le budget dans les scènes les plus défavorables.
- Limitez le FPS pour réduire les pics de charge transitoires et stabiliser le rythme.
- Ajustez les paramètres de streaming si exposés (taille du pool, distance de prélecture). Plus grand n’est pas toujours mieux ; plus grand peut signifier « thrash plus lentement mais plus longtemps ».
Tâches pratiques avec commandes (ce que ça signifie, ce que vous décidez)
Ceci est volontairement ennuyeux. L’ennui, c’est bien ; l’ennui, c’est reproductible. Les commandes supposent Linux avec des outils courants parce que c’est là que les habitudes SRE sont les plus faciles à démontrer, mais la logique s’applique partout.
1) Identifier votre GPU et le pilote
cr0x@server:~$ lspci -nn | grep -Ei 'vga|3d|display'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2782] (rev a1)
Ce que signifie la sortie : Confirme quel GPU est présent et quel périphérique PCI nous examinons. Utile avec des configurations hybrides ou sessions à distance.
Décision : Si le GPU n’est pas celui que vous pensez utiliser, arrêtez-vous et corrigez cela avant d’ajuster quoi que ce soit.
2) Vérifier l’utilisation VRAM NVIDIA et les consommateurs par processus (si applicable)
cr0x@server:~$ nvidia-smi --query-gpu=name,driver_version,memory.total,memory.used,memory.free --format=csv
name, driver_version, memory.total [MiB], memory.used [MiB], memory.free [MiB]
NVIDIA GeForce RTX 4070, 550.54.14, 12282 MiB, 10321 MiB, 1961 MiB
Ce que signifie la sortie : Total vs utilisé vs libre de VRAM. Si utilisé est élevé pendant les saccades, vous êtes probablement près d’une limite de résidence.
Décision : Si « libre » est constamment sous ~10–15 % dans la scène problématique, traitez les textures Ultra comme suspectes jusqu’à preuve du contraire.
cr0x@server:~$ nvidia-smi pmon -c 1
# gpu pid type sm mem enc dec fb command
0 28144 G 62 48 0 0 9920 game.bin
0 2331 G 2 1 0 0 180 Xorg
Ce que signifie la sortie : Vue rapide des processus consommant la mémoire framebuffer (fb). « mem » ici est un pourcentage d’utilisation, pas des MiB.
Décision : Si des processus en arrière-plan retiennent des centaines de Mio (enregistreurs, navigateurs avec accélération GPU), tuez-les ou isolez-les avant de blâmer le jeu.
3) Vérifier les infos mémoire GPU AMD (si applicable)
cr0x@server:~$ cat /sys/class/drm/card0/device/mem_info_vram_total
17179869184
cr0x@server:~$ cat /sys/class/drm/card0/device/mem_info_vram_used
12884901888
Ce que signifie la sortie : Octets bruts de VRAM totale et utilisée tels que rapportés par le pilote noyau.
Décision : Convertissez mentalement en Gio (diviser par 1024^3). Si utilisé est proche du total pendant une saccade, baissez les textures ou réduisez d’autres fonctionnalités gourmandes en VRAM (RT, ombres haute résolution, grands caches).
4) Vérifier que votre lien PCIe n’est pas dégradé
cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -E 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16
Ce que signifie la sortie : Capacité du lien vs lien négocié réel. Si vous êtes en x4 ou à une vitesse inférieure, les coûts de paging sont plus coûteux.
Décision : Si le lien est dégradé de façon inattendue, reseatez la carte, vérifiez les paramètres du BIOS, et ne changez pas encore les réglages de textures.
5) Vérifier la saturation CPU par cœur pendant la reproduction des saccades
cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0 (server) 01/21/2026 _x86_64_ (16 CPU)
12:04:10 PM CPU %usr %sys %iowait %idle
12:04:11 PM all 22.11 6.18 1.02 70.69
12:04:11 PM 7 92.00 5.00 0.00 3.00
Ce que signifie la sortie : Un cœur (CPU 7) est saturé. Cela peut être le thread de rendu, le thread de streaming, ou du travail du pilote.
Décision : Si un seul cœur est bloqué lors des saccades, abaisser les textures peut aider indirectement (moins de travail de streaming), mais vous devriez aussi essayer de réduire les paramètres gourmands en draw-call (distance de vue, densité de foule) et vérifier les processus CPU en arrière-plan.
6) Vérifier la latence et la saturation du stockage pendant le streaming
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
21.2 0.0 6.1 1.0 0.0 71.7
Device r/s rkB/s await %util
nvme0n1 210.0 82000.0 3.20 62.0
Ce que signifie la sortie : « await » est le temps moyen par I/O. %util montre la saturation du périphérique. Si await augmente pendant les à-coups, le stockage est impliqué.
Décision : Si %util approche 100 % et que await est élevé quand vous avez des à-coups, déplacer le jeu vers un SSD plus rapide ou réduire la demande de streaming (textures, distance de vue) aidera.
7) Vérifier que le système n’échange pas massivement au niveau OS
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 0 8123456 221000 9021000 0 0 120 340 900 2100 22 6 71 1
Ce que signifie la sortie : « si/so » sont swap-in/out. Si ceux-ci sont non nuls pendant les saccades, vous n’êtes pas seulement à court de VRAM ; vous manquez aussi de mémoire système.
Décision : Si du swapping se produit : fermez les applications en arrière-plan, ajoutez de la RAM, baissez la qualité des textures, et assurez-vous que le fichier d’échange/swap est sur SSD (et dimensionné correctement).
8) Observer l’utilisation des moteurs GPU (vérification de bon sens)
cr0x@server:~$ sudo intel_gpu_top -s 200 -o -
requesting drm device 0, main kdev 0, minor 0
Render/3D 12.32% Blitter 0.00% Video 0.00%
Ce que signifie la sortie : Sur les systèmes iGPU Intel, montre si le GPU est réellement occupé. Une faible utilisation avec de mauvais temps de trame pointe souvent vers des stalls CPU ou mémoire.
Décision : Si l’utilisation est faible pendant les saccades, ne cherchez pas « plus de GPU ». Cherchez la source du stall (paging VRAM, thread CPU, I/O, compilation de shaders).
9) Vérifier le compositeur / mode d’affichage (VRR et comportement plein écran)
cr0x@server:~$ xrandr --verbose | grep -E 'connected|vrr_capable|vrr_enabled'
DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis)
vrr_capable: 1
vrr_enabled: 1
Ce que signifie la sortie : Le support de rafraîchissement variable est activé. Le VRR peut masquer de petites variations de temps de trame mais ne vous sauvera pas de coups de 200 ms.
Décision : Si VRR est désactivé, activez-le pour plus de confort. Si VRR est activé et que vous avez toujours des à-coups, vous traitez des gros pics (streaming/paging).
10) Confirmer quel système de fichiers et l’espace libre (le streaming déteste les disques pleins)
cr0x@server:~$ df -hT /mnt/games
Filesystem Type Size Used Avail Use% Mounted on
/dev/nvme0n1p2 ext4 930G 870G 13G 99% /mnt/games
Ce que signifie la sortie : 99 % d’utilisation est un signe de mauvaise performance. La fragmentation et le comportement de collecte peuvent augmenter la latence.
Décision : Libérez de l’espace. Visez au moins 10–15 % de marge. Puis retestez les saccades avant de toucher plus de réglages.
11) Surveiller en temps réel les pics de latence I/O avec iotop
cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 75.21 M/s | Total DISK WRITE: 2.11 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
28144 be/4 cr0x 62.10 M/s 0.00 B/s 0.00 % 9.21% game.bin
Ce que signifie la sortie : Le jeu charge beaucoup de données. C’est normal pendant le streaming, mais si cela coïncide avec des à-coups et que votre disque est lent/saturé, vous avez trouvé un contributeur.
Décision : Si les taux de lecture sont élevés et que votre disque est saturé, réduisez la demande de streaming (textures/distance de vue) ou déplacez l’installation sur un stockage plus rapide.
12) Valider la marge de mémoire système
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 32Gi 26Gi 1.2Gi 1.1Gi 4.8Gi 3.9Gi
Swap: 8Gi 0.0Gi 8Gi
Ce que signifie la sortie : « available » est ce qui compte. Si c’est bas, l’OS vous combattra.
Décision : Si la mémoire disponible est sous ~3–4 Gio pendant le jeu, attendez-vous à plus de paging et de pires saccades quand la VRAM est tendue. Fermez des choses ou ajoutez de la RAM.
13) Vérifier la taille et l’emplacement du cache de shaders (sanité pratique)
cr0x@server:~$ du -sh ~/.cache/* 2>/dev/null | sort -h | tail -n 5
1.2G /home/cr0x/.cache/mesa_shader_cache
2.8G /home/cr0x/.cache/game-shader-cache
Ce que signifie la sortie : Les gros caches de shaders sont normaux. Si votre répertoire home est sur un disque lent ou presque plein, la compilation et l’écriture du cache peuvent provoquer des saccades.
Décision : Assurez-vous que les caches résident sur un SSD et qu’il y a de la marge. Ne supprimez pas les caches systématiquement à moins de dépanner une corruption.
14) Mesurer le pacing des images via les statistiques de present (approche basique)
cr0x@server:~$ mangohud --dlsym ./game.bin
MangoHud: HUD initialized
Ce que signifie la sortie : Vous lancez avec un overlay de temps de trame. Vous vous souciez plus du graphe des temps de trame que du nombre de FPS.
Décision : Si le graphe montre des pics périodiques qui disparaissent après avoir baissé la qualité des textures, vous regardez un stress de streaming/de résidence VRAM, pas du débit GPU brut.
Trois mini-récits d’entreprise depuis le terrain
1) Incident causé par une mauvaise hypothèse : « La VRAM, c’est comme la RAM, ça fera juste mieux le cache »
Un studio avec lequel j’ai travaillé (appelons-les Société A) a publié un patch PC qui « améliorait le visuel » en augmentant la qualité par défaut des textures sur les GPU haut de gamme. Le changement était justifié par une formule familière : la plupart des cartes avaient maintenant assez de VRAM, et la VRAM inutilisée est gaspillée.
Ils ont testé sur une poignée de machines en labo. Les framerates semblaient corrects. Pas de crash. Le patch est sorti un mardi, parce que bien sûr.
En quelques heures, les canaux de support se sont remplis de rapports : « micro-saccades après 20 minutes », « à-coups en tournant », « bien au début, puis terrible ». Le comble : beaucoup de rapports venaient de cartes 8–10 Gio qui auraient dû être « sûres ». L’hypothèse a échoué parce que la VRAM n’est pas un cache passif. C’est une contrainte de résidence, et les moteurs peuvent faire de mauvais paris sur les mouvements futurs de la caméra. Un joueur avec un FOV large, des rotations rapides et une monture rapide était effectivement un benchmark worst-case de streaming.
Le post-mortem a montré que le changement par défaut avait poussé l’usage typique de la VRAM de « confortable » à « au rasoir », et la politique d’éviction du moteur a commencé à osciller. L’oscillation est l’ennemi dans tous les systèmes : une fois que vous thrash, le travail que vous faites crée plus de travail. Boucle de rétroaction positive classique.
La correction n’a pas été héroïque. Ils ont rétabli la valeur par défaut, ajouté un avertissement cartographiant les presets de textures à la marge VRAM, et ajusté le pool de streaming pour se comporter plus prudemment sous pression. La plus grande leçon n’était pas sur les textures ; c’était sur l’hypothèse que la capacité se comporte de façon linéaire. Ce n’est pas le cas.
2) Optimisation contraproduite : « Réduisons la mémoire des textures avec des baisses agressives de mip »
La Société B avait un vrai problème : sur les GPU milieu de gamme, l’usage VRAM était trop élevé dans les villes denses. Quelqu’un a proposé une idée intelligente : réduire dynamiquement les mips plus agressivement dès que la VRAM approchait du budget. En théorie, cela maintiendrait le jeu dans sa voie et éviterait les à-coups.
Le premier test interne semblait prometteur. L’usage VRAM s’est aplati. Moins de stalls durs. Tout le monde acquiesçait. Puis la QA a commencé à faire ce que la QA fait : rester immobile et tourner lentement la caméra, encore et encore, au même endroit.
La ville est devenue un bazar scintillant. Les textures poppaient constamment. Pire, le moteur a commencé à « yo-yoer » les mips : baisser les mips pour réduire la VRAM, de l’espace libre apparaît, le moteur remonte les mips, la VRAM monte, baisse à nouveau. Le résultat était une VRAM stable mais des visuels instables et un travail de fond continu. Ils ont échangé une forme de stall contre une autre : au lieu de rares gros à-coups, ils ont obtenu un jank constant de bas niveau.
En termes systèmes, ils ont implémenté un contrôleur sans amortissement et avec des seuils trop agressifs. C’était un thermostat qui allume le chauffage à plein régime à 19,9 °C et l’éteint à 20,0 °C. Félicitations, vous avez inventé l’oscillation.
La solution finale a été d’ajouter de l’hystérésis (ne pas remonter immédiatement les mips après une baisse), de limiter la vitesse de changement des mips par seconde, et de préférer réduire les requêtes de streaming futures plutôt que d’évincer des assets actuellement visibles. L’« optimisation » n’était pas fausse ; elle était incomplète. En travail de performance, l’incomplet est la façon d’envoyer de nouveaux problèmes à temps.
3) Pratique ennuyeuse mais correcte qui a sauvé la situation : « Budgets, instrumentation, et un ‘non’ ferme aux changements silencieux »
La Société C n’avait pas le moteur le plus glamour, mais elle avait une discipline presque old-school : un tableau de budget VRAM par plateforme et par niveau de qualité, revu comme un SLO. Pas « à peu près ». Un vrai tableau.
Chaque build recueillait de la télémétrie depuis les playtests internes : textures résidentes pics, profondeur moyenne de la queue de streaming, nombre d’évictions par minute, pire percentile de temps de trame. Si vous changiez les presets de textures, il fallait montrer les métriques. Si vous ajoutiez une nouvelle bibliothèque de matériaux, il fallait montrer l’impact sur le budget. Si vous ne le faisiez pas, votre changement ne passait pas.
Quand du contenu de dernière minute a poussé la carte de la ville près du budget, ils n’ont pas paniqué. Ils savaient déjà quels groupes d’assets étaient les pires coupables. Ils ont baissé certaines résolutions de normal maps, ajusté quelques instances de matériaux, et remplacé une poignée de props « héros » qui ne méritaient pas des textures héroïques.
La sortie avait toujours des bugs, parce que le logiciel en a toujours. Mais ils n’ont pas eu la fiasco signature « Ultra fait ramer le jeu sur du hardware parfaitement normal ». La pratique ennuyeuse — budgets, instrumentation et refus des changements silencieux — a fait ce que les pratiques ennuyeuses font : prévenir des incidents excitants.
Erreurs courantes : symptôme → cause → réparation
1) « Le FPS est élevé, mais ça fait terrible quand je tourne »
Cause : Stalls de streaming de textures ou surconsommation VRAM provoquant évictions/uploads pendant le mouvement de la caméra.
Réparation : Baissez la qualité des textures d’un cran ; réduisez la distance de vue ; assurez-vous que le jeu est sur SSD ; gardez l’usage VRAM sous ~85–90 % dans les pires scènes.
2) « Baisser la résolution n’a pas corrigé les saccades »
Cause : Vous avez réduit la charge des render-targets, mais votre goulot est la résidence des assets et le streaming, pas le pixel shading.
Réparation : Baissez les textures et/ou les paramètres de streaming ; réduisez les ombres haute résolution ; désactivez les packs de textures haute résolution qui dépassent votre VRAM.
3) « Ça tourne bien 10 minutes, puis ça empire »
Cause : Le jeu de travail croît au fur et à mesure de la traversée ; les caches se remplissent ; des applications en arrière-plan s’installent ; la VRAM devient fragmentée ou le budget diminue à cause d’autres allocations.
Réparation : Fermez les applis GPU-intensives en arrière-plan ; redémarrez le jeu entre de longues sessions comme contournement ; ajustez les textures pour les zones pires, pas pour la zone tutorielle.
4) « Les textures Ultra ressemblent aux High, mais les performances plongent »
Cause : Vous êtes limité par l’empreinte mémoire/bande passante, pas par la perception du détail. Beaucoup de scènes sont de toute façon limitées par les mips en mouvement.
Réparation : Restez en High. Dépensez le budget sur le filtrage anisotrope (généralement peu coûteux) ou sur de meilleurs réglages d’éclairage qui changent réellement la scène.
5) « Le pop-in des textures est affreux en Medium »
Cause : Pool de streaming trop petit ou biais de mip trop agressif, provoquant des transitions de mip visibles.
Réparation : Augmentez la qualité des textures d’un cran, ou augmentez le pool de streaming si le moteur l’expose — mais seulement si vous avez de la marge en VRAM.
6) « L’overlay VRAM dit que j’utilise 11 Gio sur une carte 12 Gio, donc tout va bien »
Cause : Être « presque plein » n’est pas OK. Il y a des pics. L’overhead du pilote existe. Le moteur peut allouer en rafale lors des transitions.
Réparation : Visez une marge. Traitez 90 % comme « jaune », pas comme « vert », dans les scènes où le jeu a du mal.
7) « Après activation du ray tracing, les textures ont commencé à saccader »
Cause : Le RT alloue souvent de grands buffers (BVH, historique de denoiser, render targets supplémentaires), réduisant la VRAM disponible pour les textures.
Réparation : Si vous voulez RT, baissez les textures ou les ombres. Si vous voulez des textures nettes, baissez le RT. Choisissez un luxe à la fois sauf si vous avez sérieusement de la VRAM.
8) « J’ai installé un pack de textures haute résolution et maintenant tout saccade »
Cause : Le pack a augmenté le jeu de travail au-delà de la VRAM ; le paging sur PCIe fait maintenant partie de votre boucle de frame.
Réparation : Désinstallez le pack, ou acceptez des textures plus basses ailleurs. Les packs haute résolution ne sont pas des « mises à niveau gratuites ». Ce sont des décisions de capacité.
Listes de contrôle / plan étape par étape
Checklist A : choisir le bon niveau de textures en 15 minutes
- Trouvez une scène worst-case : ville dense, beaucoup de matériaux uniques, traversée rapide.
- Activez un overlay de temps de trame (pas seulement le FPS).
- Mettez les textures sur Ultra ; jouez 2 minutes ; notez le pic de VRAM et les pires pics de temps de trame.
- Mettez les textures sur High ; répétez exactement le même chemin ; comparez les pics et le pic de VRAM.
- Si High élimine les pics majeurs et qu’Ultra n’apporte pas d’amélioration significative en mouvement, restez en High.
- Si Ultra est fluide et qu’il vous reste encore 10–20 % de VRAM libre dans le pire cas, félicitations : Ultra est pour vous.
Checklist B : stabiliser un système qui saccade sous charge VRAM
- Fermez les applis GPU-intensives en arrière-plan (navigateurs avec beaucoup d’onglets, enregistreurs, overlays inutiles).
- Assurez-vous que le jeu est installé sur un SSD avec >15 % d’espace libre sur ce volume.
- Baissez les textures d’un cran ; retestez.
- Si c’est toujours mauvais : réduisez RT/ombras hautes résolutions ; retestez.
- Limitez légèrement le FPS sous votre moyenne typique (par ex., 120 → 90, 60 → 50). Cela réduit l’explosivité.
- Ce n’est qu’ensuite que vous devriez envisager un scaling de résolution.
Checklist C : règles « Ultra sans regret »
- Les textures Ultra sont justifiées quand vous avez de la marge VRAM dans les pires scènes et que vous jouez assez lentement pour remarquer le détail de surface.
- Les textures Ultra ne sont pas justifiées quand elles poussent la VRAM à la limite, surtout dans les jeux en monde ouvert.
- Si vous streamez du contenu (capture/encodage) en jouant, supposez que vous avez besoin de plus de marge que dans un scénario « jeu pur ».
- Si le jeu propose un « pack de textures haute résolution », traitez-le comme une exigence matérielle, pas comme un ornement cosmétique.
FAQ
1) L’utilisation de la VRAM est-elle censée être proche de 100 % ?
Non. Un système sain utilise la VRAM mais garde de la marge. 95–100 % dans des scènes exigeantes est l’endroit où le paging et les tempêtes d’éviction commencent.
2) Pourquoi les textures causent-elles plus de saccades que d’autres réglages ?
Parce que les textures sont volumineuses et nombreuses, et la pénalité pour manquer une texture nécessaire est souvent une attente synchrone : éviction, upload, décompression, puis draw.
3) Si mon GPU a beaucoup de calcul, pourquoi ne peut-il pas « forcer » le passage ?
Le calcul n’aide pas si les données ne sont pas résidentes. Un GPU rapide qui attend un upload de texture attend toujours. Ce n’est pas un concours de puissance ; c’est un échec logistique.
4) Baisser la résolution réduit-il l’utilisation de la VRAM ?
Cela réduit la mémoire des render-targets et certains caches, mais cela peut ne pas réduire de manière significative la résidence des textures. C’est pourquoi la baisse de résolution ne corrige souvent pas les saccades liées aux textures.
5) Les textures « High » et « Ultra » sont-elles visiblement différentes ?
Parfois sur des images fixes. Souvent pas en mouvement, surtout avec TAA, la profondeur de champ et des distances de caméra typiques. Si vous ne le voyez pas en jeu, ne payez pas la taxe VRAM.
6) Quelle est la différence entre la VRAM « allouée » et la VRAM « utilisée » ?
Alloué peut signifier de l’espace d’adresses réservé ou des ressources engagées. Utilisé/resident signifie réellement occupé dans la VRAM locale. Les outils varient ; ne supposez pas qu’un overlay soit la référence.
7) Un SSD peut-il résoudre les problèmes de VRAM ?
Un SSD aide le streaming, pas la résidence. Il peut réduire la gravité des à-coups en faisant arriver les données plus vite, mais il ne remplace pas la bande passante et la latence de la VRAM locale.
8) Dois-je désactiver le streaming de textures ?
Seulement si le jeu le supporte bien et que vous avez une VRAM massive. Désactiver le streaming augmente souvent les chargements initiaux et peut accroître la demande totale en VRAM. Testez, ne devinez pas.
9) Pourquoi le ray tracing affecte-t-il la fluidité des textures ?
Les fonctionnalités RT consomment de la VRAM pour les structures d’accélération et les buffers d’historique. Cela réduit le budget mémoire disponible pour la résidence des textures et les pools de streaming.
10) Quel réglage unique est le meilleur rapport qualité/prix si je baisse les textures ?
Le filtrage anisotrope est généralement peu coûteux et améliore la netteté des textures en angle. Gardez-le élevé pendant que vous réduisez la résolution des textures.
Prochaines étapes concrètes
Si votre approche actuelle est « tout en Ultra et on espère », remplacez-la par un processus :
- Choisissez une scène worst-case et mesurez la VRAM et les pics de temps de trame.
- Baissez les textures d’un cran et relancez le même parcours. Si les pics diminuent, gardez le réglage inférieur et passez à autre chose.
- Protégez la marge : visez des pics de VRAM qui laissent 10–20 % de libre dans les scènes qui comptent.
- Dépensez votre budget là où vous le ressentez : pacing stable, ombres sensées, et AF plutôt que des points de prestige.
- Quand vous changez une chose, ne changez qu’une chose. Le tuning, c’est du debug, pas un rituel.
Ultra n’est pas un badge d’honneur. C’est une politique de ressources. Faites-en une politique que vous pouvez vous permettre.