FSR expliqué : comment AMD a rendu l’upscaling grand public

Pourquoi l’upscaling a gagné (et pourquoi FSR a compté)

Le rendu natif est l’histoire la plus propre que vous puissiez raconter. C’est aussi l’histoire la plus coûteuse à livrer.
Les piles de rendu modernes sont gourmandes : matériaux basés physiquement, volumétrie, ray tracing, post-traitement intensif, et assez
de shaders pour donner l’impression que votre GPU fait vos impôts.

L’upscaling a gagné parce que c’est le seul levier qui déplace de façon fiable la qualité d’image et les performances sans repenser toute la frame.
Réduisez la résolution interne, reconstruisez le détail manquant, et dépensez le budget économisé ailleurs : meilleur éclairage, plus grande distance de vue,
temps de frame plus stables. C’est un compromis, mais tout en production l’est.

AMD a rendu l’upscaling grand public non pas parce que FSR était « le meilleur » dans chaque comparaison instantanée, mais parce qu’il était déployable.
Il était ouvert, multi-fournisseur, et ne réclamait pas une voie spécifique d’accélérateur IA. Cela a permis aux studios de le traiter comme une fonctionnalité,
pas comme une négociation de partenariat.

Ce que « grand public » signifie réellement en termes d’exploitation

Grand public signifie que votre fonctionnalité devient partie de l’arbre de dépannage par défaut. Elle devient quelque chose que l’assurance qualité bascule,
quelque chose que le support interroge, et quelque chose dont les budgets de performance supposent qu’il sera activé sur une large partie des systèmes.
Grand public signifie aussi que vous ne pouvez pas le traiter comme un « optionnel agréable à avoir ». Quand il échoue, il échoue bruyamment.

Si vous gérez un produit en ligne, vous connaissez déjà le schéma : une nouvelle fonctionnalité graphique est livrée ; la moitié de vos joueurs ne l’utilise jamais ;
un quart l’active et est content ; un dix pour cent obstiné l’utilise dans des combinaisons étranges avec des overlays, outils de capture, modes VRR,
et des branches de pilotes mises à jour pour la dernière fois sous une administration précédente. Ce dix pour cent est là où vit votre pager.

FSR 1, 2, 3 : l’arbre généalogique sans le brouillard marketing

FSR 1 : upscaling spatial plus netteté

FSR 1 est un sur-échantillonneur spatial. Il examine une seule image et tente de l’agrandir en utilisant une logique consciente des bords, puis applique un renforcement
(RCAS) pour contrer le flou. Il ne « connaît » pas le mouvement. Il n’utilise pas l’historique. Il est rapide, simple et facile à intégrer.
Il peut aussi ressembler à une supposition très confiante quand le contenu est complexe.

L’avantage opérationnel est énorme : moins d’entrées, moins de pièges d’intégration, moins de façons d’être subtilement faux.
L’inconvénient est tout aussi pratique : vous ne pouvez reconstruire qu’une certaine quantité à partir d’une seule image. Les détails fins à basse résolution d’entrée deviennent
de la pensée souhaitée. Un upscaler spatial peut être stable ou net, mais il a souvent du mal à être les deux.

FSR 2 : reconstruction temporelle (la version adulte)

FSR 2 est un upscaling temporel. Il utilise plusieurs images, des vecteurs de mouvement, la profondeur et des informations d’exposition pour reconstruire le détail dans le temps.
C’est la catégorie « sérieuse » : c’est là que la qualité augmente, et où les erreurs d’intégration deviennent visibles sous forme de ghosting, scintillement,
UI cassée ou désoccultation bruyante.

Les techniques temporelles sont puissantes parce qu’elles récoltent de l’information dans le temps. Elles sont aussi fragiles parce que le temps est l’endroit
où chaque moteur a ses propres péchés : motifs de jitter, gestion d’historique TAA, masquage réactif, transparence, particules et post-effets qui
n’ont jamais été conçus pour être « reprojetés ».

FSR 3 : la génération de frames entre en jeu

FSR 3 ajoute la génération de frames (interpolation) plus une gestion de latence de type anti-lag (selon l’implémentation).
Il peut augmenter drastiquement le FPS affiché en synthétisant des frames intermédiaires à partir du mouvement.
Ce n’est pas la même chose que « plus de performances ». Ce sont plus d’images affichées ; votre simulation peut toujours s’exécuter au même rythme.

La génération de frames est l’endroit où vous cessez de parler de FPS moyen et commencez à parler d’ordonnancement des frames, latence d’entrée et d’artefacts
lors de mouvements rapides. C’est aussi l’endroit où « mon benchmark indique 160 FPS » rencontre « pourquoi ça ressemble à 60 ? »

Une règle pratique courte : si votre taux de base est instable ou faible, la génération de frames peut rendre l’instabilité visuellement plus fluide
tandis que votre latence d’entrée reste insensible.

Comment FSR fonctionne en coulisses (ce dont il a besoin, ce qu’il casse)

Spatial vs temporel : la vraie différence

L’upscaling spatial est une transformation par image. Il voit des pixels et des bords. Il n’a pas de mémoire.
C’est pourquoi il est robuste et pourquoi il ne peut pas reconstruire magiquement du détail sous-pixel.

L’upscaling temporel traite l’image courante comme un échantillon d’une série temporelle. Il suppose que les vecteurs de mouvement sont corrects,
que la profondeur est cohérente, que le jitter est connu et constant, et que votre moteur lui fournit des entrées propres.
Quand ces hypothèses tiennent, le résultat est impressionnant. Quand elles ne tiennent pas, le résultat est « pourquoi mon arme laisse-t-elle une traînée ? »

Les entrées attendues par les upscalers temporels de type FSR 2

• Vecteurs de mouvement représentant le mouvement des pixels/géométrie entre les frames.
• Buffer de profondeur pour la gestion des désoccultations et les décisions de reconstruction.
• Offset de jitter et un motif de jitter de caméra cohérent.
• Exposition / pré-exposition afin que le mélange d’historique n’explose pas lors des changements de luminosité.
• Masques réactifs / de transparence pour réduire le ghosting sur particules, eau et éléments de type UI.

En ratez une, et vous pouvez toujours expédier. Vous expédiez juste un mystère.

Où l’intégration a tendance à mal tourner

Le plus gros mode d’échec n’est pas « l’algorithme est mauvais ». C’est « les entrées mentent ».
Des vecteurs de mouvement qui n’incluent pas les maillages skinning animés. Des vecteurs générés dans un espace différent de celui attendu.
Une profondeur post-traitée ou inversée sans configuration correspondante.
Du jitter appliqué à un passe mais pas à celle qui alimente les vecteurs.
Une UI dessinée avant l’upscaling puis traitée comme si c’était partie du monde.

Les upscalers sont comme la supervision : ils amplifient fidèlement ce que vous leur donnez, y compris vos erreurs.

Netteté : un bouton de qualité qui double comme générateur de plaintes clients

Le renforcement est séduisant. Il rend les captures d’écran nettes. Il rend aussi le scintillement de mouvement, l’aliasing des textures et le bruit spéculaire
plus visibles. Votre meilleur réglage par défaut de netteté est rarement « le plus net ». C’est celui qui ne transforme pas le feuillage en essaim d’abeilles.

Blague n°1 : Monter la netteté à 100 % c’est comme crier en réunion — techniquement vous êtes plus clair, mais personne n’est plus heureux.

Génération de frames : pourquoi les opérationnels doivent s’en soucier

La génération de frames change la nature des plaintes. Vous verrez moins de tickets « faible FPS » et plus de « ça donne une sensation de latence »,
« la souris est flottante », et « artefacts lors des rotations rapides ».
Si vous gérez des tableaux de bord de performance, arrêtez de traiter le FPS comme KPI unique. Commencez à suivre :
le 99e percentile du temps de frame, la variance du temps de frame, et les marqueurs de latence.

Une citation fiabilité qui appartient à chaque revue de performance :
« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

Vous ne « comptez pas sur l’espoir » pour que le moteur fournisse des vecteurs corrects. Vous le vérifiez avec des outils de capture et des tests reproductibles.

Benchmark pratique : mesurer ce que les joueurs ressentent

Pourquoi le FPS moyen est un piège

Le FPS moyen est une valeur moyenne qui cache ce que les joueurs perçoivent réellement : l’incohérence.
Un jeu peut être à 120 FPS en moyenne et donner une mauvaise sensation s’il a des pics de temps de frame toutes les quelques secondes.
L’upscaling peut augmenter la moyenne tout en laissant les pics intacts parce que les pics proviennent de blocages CPU, compilation de shaders,
streaming ou points de synchronisation.

Faites du benchmarking comme un SRE, pas comme une diapositive marketing

La boucle est simple :
définir la charge → contrôler les variables → capturer les temps de frame → comparer les distributions → interpréter le goulet.
Si vous ne pouvez pas relancer exactement le même chemin de scène, votre benchmark est un check de vibes, pas des données.

Prenez des décisions basées sur :
le temps médian de frame, p95, p99, et p99.9 si possible.
Puis validez avec une mesure de latence d’entrée si vous utilisez la génération de frames.

Les modes de qualité ne sont pas juste « performance vs qualité »

Les modes classiques (Quality, Balanced, Performance, Ultra Performance) sont en réalité différentes résolutions d’entrée et budgets de reconstruction.
Baisser la résolution d’entrée peut exposer des problèmes :
géométrie fine qui scintille, motifs moiré, pop LOD agressif, aliasing spéculaire.
Parfois « Balanced » paraît mieux que « Performance » non pas parce que l’algorithme change, mais parce que l’entrée cesse de le priver.

Décidez ce que vous optimisez

Si vous ciblez des TV 60 Hz, vous optimisez la stabilité et le pacing constant.
Si vous ciblez des moniteurs esports à haute fréquence, vous optimisez la latence et les artefacts minimaux lors de mouvements rapides.
Les réglages FSR (et l’usage de la génération de frames) doivent suivre cette décision, pas l’inverse.

Tâches pratiques : 12+ commandes réelles, sorties, et décisions

Voici des tâches pratiques que vous pouvez exécuter sur une machine Linux de jeu/poste de travail ou une machine de build/QA pour diagnostiquer GPU/CPU/pilote et
problèmes d’ordonnancement autour de l’upscaling. L’objectif n’est pas de « prouver que FSR est bon ». L’objectif est de trouver la contrainte et corriger le pipeline.

Tâche 1 : Confirmer GPU, pilote et bases du noyau

cr0x@server:~$ uname -r
6.8.0-41-generic

Ce que cela signifie : La version du noyau peut affecter le comportement du scheduler et la compatibilité du pilote GPU.

Décision : Si vous êtes sur un noyau LTS ancien avec des GPU récents, testez une pile noyau/pilote plus récente avant d’accuser les artefacts FSR.

cr0x@server:~$ lspci -nn | grep -E "VGA|3D"
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700 XT] [1002:73df]

Ce que cela signifie : Confirme le modèle GPU réel. Cela compte pour le support des fonctionnalités et les performances attendues.

Décision : Utilisez ceci pour catégoriser les machines de test ; ne comparez pas des résultats entre différentes gammes de GPU et n’attribuez pas cela à une « variance FSR ».

Tâche 2 : Vérifier les versions Mesa/pilote (coupable silencieux fréquent)

cr0x@server:~$ glxinfo -B | sed -n '1,25p'
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon RX 6700 XT (radeonsi, navi22, LLVM 17.0.6, DRM 3.57, 6.8.0-41-generic) (0x73df)
    Version: 24.1.3
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.1.3

Ce que cela signifie : Identifie la version de Mesa et le chemin du pilote. Beaucoup de plaintes FSR sont des régressions de pilote ou des bizarreries du compilateur de shaders.

Décision : Si des artefacts apparaissent « après une mise à jour », figez ou bisectez les versions Mesa/pilote. Ne réglez pas la netteté pour masquer une régression.

Tâche 3 : Vérifier l’identité du pilote Vulkan (FSR souvent utilisé dans les titres Vulkan)

cr0x@server:~$ vulkaninfo --summary | sed -n '1,40p'
VULKANINFO SUMMARY
==================
Instance Version: 1.3.283

Devices:
========
GPU0:
    apiVersion         = 1.3.280
    driverVersion      = 2.0.310
    vendorID           = 0x1002
    deviceID           = 0x73df
    deviceName         = AMD Radeon RX 6700 XT

Ce que cela signifie : Confirme la version Vulkan et le périphérique utilisé.

Décision : Si vous voyez le mauvais GPU (iGPU), forcez la sélection du GPU discret avant d’investiguer la qualité/perf FSR.

Tâche 4 : Identifier si vous êtes lié CPU ou GPU à l’exécution

cr0x@server:~$ sudo apt-get install -y mangohud
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  mangohud
0 upgraded, 1 newly installed, 0 to remove and 12 not upgraded.

Ce que cela signifie : MangoHud fournit des graphes de temps de frame et un overlay de métriques GPU/CPU pour Vulkan/OpenGL.

Décision : Utilisez-le pour déterminer si FSR (levier côté GPU) peut réellement aider votre goulet.

cr0x@server:~$ mangohud --dlsym vkcube
MangoHud: Uploading is disabled (permit_upload = 0)

Ce que cela signifie : Vous pouvez injecter l’overlay dans une application Vulkan. Dans un jeu, vous lanceriez via les options de lancement Steam de manière similaire.

Décision : Si l’utilisation GPU est faible alors que les temps de frame sont élevés, arrêtez de bidouiller FSR en premier ; vous êtes probablement limité par le CPU/IO.

Tâche 5 : Capturer les bases de l’ordonnancement des frames (mode de présentation et rafraîchissement)

cr0x@server:~$ xrandr --verbose | sed -n '1,40p'
Screen 0: minimum 8 x 8, current 2560 x 1440, maximum 32767 x 32767
DisplayPort-0 connected primary 2560x1440+0+0 (0x4a) normal (normal left inverted right x axis y axis) 597mm x 336mm
	2560x1440     165.00*+  144.00    120.00    60.00

Ce que cela signifie : Affiche le taux de rafraîchissement et le mode courant.

Décision : Lors de l’évaluation de la génération de frames FSR 3, verrouillez le test sur une cible de rafraîchissement fixe (par ex. 120 Hz) pour interpréter le pacing.

Tâche 6 : Vérifier le gouverneur CPU (classique « pourquoi ça saccade sur les portables »)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Ce que cela signifie : Le CPU privilégie l’économie d’énergie ; la réponse de boost peut être plus lente, augmentant les pics de temps de frame.

Décision : Passez en performance pour le benchmarking ; sinon vous mesurez la politique d’alimentation, pas l’upscaling.

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Ce que cela signifie : Définit le gouverneur en mode performance pour des tests stables.

Décision : Relancez votre capture après ce changement. Si les pics diminuent, documentez la politique d’alimentation comme partie de vos étapes de repro.

Tâche 7 : Confirmer que vous n’êtes pas en throttling thermique

cr0x@server:~$ sensors | sed -n '1,40p'
amdgpu-pci-0300
Adapter: PCI adapter
edge:         +76.0°C  (crit = +100.0°C, hyst = -273.1°C)
junction:      +92.0°C  (crit = +110.0°C, hyst = -273.1°C)

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +83.5°C

Ce que cela signifie : Des températures de jonction élevées peuvent induire des baisses d’horloge GPU ; Tctl CPU peut brider le boost.

Décision : Si les clocks chutent pendant les scènes lourdes, corrigez le refroidissement ou les limites d’alimentation avant de juger les modes FSR.

Tâche 8 : Observer les clocks GPU et l’utilisation sous charge

cr0x@server:~$ sudo radeontop -d - -l 1 | head -n 10
Dumping to stdout
gpu 99.12%  ee 0.00%  vgt 92.45%  ta 88.12%  sx 61.33%  sh 97.44%  spi 72.88%  sc 55.11%
vram  512.00mb  gtt  238.00mb  mclk 2000.00MHz  sclk 2450.00MHz

Ce que cela signifie : Le GPU est proche de la saturation ; FSR (réduction de la résolution interne) peut aider.

Décision : Si le GPU est saturé, testez FSR Quality vs Balanced et comparez les temps de frame p99, pas seulement le FPS moyen.

Tâche 9 : Vérifier la pression VRAM (saccades qui ressemblent à « FSR est cassé »)

cr0x@server:~$ cat /proc/meminfo | grep -E "MemAvailable|SwapTotal|SwapFree"
MemAvailable:   11248320 kB
SwapTotal:       2097148 kB
SwapFree:        2097148 kB

Ce que cela signifie : La RAM système disponible est saine ; le swap inutilisé.

Décision : Si MemAvailable est bas et que le swap est utilisé, les stalls de streaming peuvent dominer ; réduisez les paramètres de texture avant d’accuser l’upscaling.

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/amdgpu_vram | head
VRAM total size: 12272 MiB
VRAM usable size: 12272 MiB
VRAM used: 10384 MiB

Ce que cela signifie : L’utilisation VRAM est élevée. L’upscaling peut réduire la taille des targets de rendu, mais les textures et la géométrie dominent toujours.

Décision : Si la VRAM utilisée approche le total, réduisez la résolution des textures ou les fonctionnalités RT ; n’attendez pas que FSR seul corrige les hitchs.

Tâche 10 : Repérer les compilations de shaders ou problèmes de cache pipeline

cr0x@server:~$ journalctl --user -b | grep -iE "shader|pipeline|vulkan" | tail -n 10
Jan 13 09:11:22 desktop steam[4121]: Fossilize INFO: Using read-only directory: /home/cr0x/.steam/steam/steamapps/shadercache
Jan 13 09:11:29 desktop steam[4121]: Fossilize INFO: Processed 128 pipeline cache entries

Ce que cela signifie : L’activité du cache pipeline indique que des compilations de shaders/création de pipelines ont lieu.

Décision : Si un saccade coïncide avec des misses de cache, réchauffez les caches lors des runs QA ; n’attribuez pas le stutter du premier lancement aux modes FSR.

Tâche 11 : Mesurer la latence IO disque (goulot de streaming d’assets)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-41-generic (desktop) 	01/13/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    3.10    2.55    0.00   82.04

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1         85.00   9200.00     0.00   0.00    1.20   108.24   42.00   2100.00     5.00  10.64    3.80    50.00    0.30  22.00

Ce que cela signifie : r_await/w_await sont faibles ; le disque n’est pas le goulet ici.

Décision : Si les await montent en flèche (dizaines de ms) pendant les hitchs, résolvez l’IO/streaming en premier. L’upscaling ne réparera pas un disque lent.

Tâche 12 : Vérifier les voleurs CPU en arrière-plan et le bruit d’ordonnancement

cr0x@server:~$ top -b -n 1 | head -n 20
top - 09:22:10 up  2:11,  1 user,  load average: 3.02, 2.41, 2.12
Tasks: 356 total,   2 running, 354 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11.3 us,  2.8 sy,  0.0 ni, 84.9 id,  0.8 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :  32036.7 total,  13420.2 free,  10412.1 used,   8204.4 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.  21624.6 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 4121 cr0x      20   0 4102328 512844 142112 S   3.3   1.6   1:12.44 steam
 2210 cr0x      20   0  834520  94128  62152 S   2.7   0.3   0:33.10 chrome

Ce que cela signifie : Le CPU global est majoritairement idle ; pas de hogs évidents. Mais navigateurs et overlays peuvent toujours introduire du jitter.

Décision : Pour une repro propre, arrêtez les applis et overlays en arrière-plan. Si le problème disparaît, documentez le conflit plutôt que « FSR instable ».

Tâche 13 : Valider le compositeur/type de session (différences Wayland/Xorg)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Ce que cela signifie : La session est Wayland. Certains outils de capture/overlay se comportent différemment que sur Xorg.

Décision : Si des problèmes de pacing n’apparaissent que sur un type de session, reproduisez sur l’autre avant de modifier les réglages d’upscaling en jeu.

Tâche 14 : Capturer un FPS de base simple et une métrique de temps de frame avec les logs MangoHud

cr0x@server:~$ mangohud --output_folder /tmp/mhud --log_duration 30 --dlsym vkcube
MangoHud: writing output to /tmp/mhud

Ce que cela signifie : Crée un log court dans /tmp/mhud avec des statistiques de temps de frame.

Décision : Lancez une fois en natif, une fois avec un mode FSR activé (dans votre jeu). Comparez les temps p99 pour décider si le mode améliore réellement la sensation.

Blague n°2 : « Ça tourne bien sur ma machine » n’est pas un benchmark ; c’est un trait de personnalité.

Guide de diagnostic rapide : trouver le goulet rapidement

Quand un joueur dit « FSR a empiré les choses », vous avez besoin d’un chemin de triage qui ne demande pas une semaine de débats autour de captures d’écran.
Voici l’ordre qui fait gagner du temps.

Première étape : classer la plainte

• Flou / étalé / doux → probablement résolution d’entrée trop basse, netteté désactivée, ou échelle de rendu incorrecte.
• Ghosting / traînées → probablement mauvais vecteurs de mouvement, masque réactif manquant, ou problèmes de transparence.
• Scintillement / bords qui rampent → aliasing, sur-nettoyage, ou historique/jitter instable.
• FPS élevé mais sensation de latence → génération de frames sans gestion de latence, base CPU limitée, tampon de présentation, mismatch VRR/VSync.
• Saccades / hitchs → streaming, compilation de shaders, pression VRAM, tâches en arrière-plan, politique d’alimentation.

Deuxième étape : décider si vous êtes GPU-bound

L’upscaling est principalement un réducteur de temps GPU. Si vous êtes CPU-bound, FSR peut peu changer ou même empirer en déplaçant
la charge vers d’autres passes. Utilisez les métriques overlay (utilisation GPU, répartition du temps de frame si disponible).

• Si le GPU est saturé et que les temps de frame diminuent en baissant la résolution → GPU-bound. FSR aide probablement.
• Si l’utilisation GPU est faible et que les temps de frame ne changent pas avec la résolution → CPU/IO-bound. Corrigez cela d’abord.

Troisième étape : vérifier les entrées temporelles (classe FSR 2)

Si les artefacts sont temporels (ghosting, détail instable), supposez que les entrées sont erronées jusqu’à preuve du contraire.
Vérifiez les vecteurs de mouvement sur les objets animés, les particules, les transparences et les coupes de caméra.

• Les vecteurs couvrent-ils les meshes skinning ?
• Sont-ils dans le bon espace de coordonnées et à la bonne échelle ?
• Le jitter est-il appliqué de façon cohérente à la couleur, profondeur et génération des vecteurs ?
• Les masques réactifs sont-ils créés pour les matériaux problématiques ?

Quatrième étape : isoler les problèmes de présentation

La génération de frames et le VRR peuvent créer des rapports « paraît fluide mais donne une mauvaise sensation ». Testez avec :
rafraîchissement fixe vs VRR, VSync activé/désactivé, cap de frame activé/désactivé, et comparez des scénarios cohérents.

Cinquième étape : ensuite seulement, ajustez la netteté et les modes par défaut

La netteté et la sélection de mode sont la dernière étape. Ne les utilisez pas pour masquer des vecteurs cassés ou des saccades.
Si vous le faites, vous livrerez une configuration qui échouera au prochain update de pilote de toute façon.

Trois mini-récits d’entreprise tirés du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Un studio de taille moyenne a déployé un patch activant un upscaler temporel par défaut sur les « GPU compatibles ».
QA avait validé la fonctionnalité sur un ensemble propre de scènes et l’avait déclarée stable. Les chiffres de performance semblaient bons.
La release est sortie un jeudi après-midi, parce que bien sûr.

En quelques heures, les tickets de support décrivaient des « traînées fantômes » derrière les personnages dans des niveaux pluvieux.
Des joueurs ont publié des clips où des gouttes et des éclaboussures laissaient des smears à l’écran, comme si l’objectif de la caméra était enduit de sirop.
L’équipe a supposé qu’il y avait un bug dans l’algorithme de l’upscaler et a ouvert un ticket auprès du fournisseur, puis a commencé à rédiger un hotfix pour le désactiver.

La cause réelle était plus petite et plus humiliante : les vecteurs de mouvement pour les systèmes de particules avaient été désactivés des mois plus tôt comme micro-optimisation.
C’était acceptable en résolution native avec le TAA standard, parce que les particules étaient majoritairement bruitées et transitoires.
L’upscaling temporel a rendu ces données manquantes visibles en réutilisant l’historique là où il ne fallait pas.

La correction n’a pas été « désactiver l’upscaling ». C’était de restaurer les vecteurs de mouvement pour la passe de particules et d’ajouter des masques réactifs pour
certains matériaux d’eau. Ils ont aussi modifié le déploiement : activation par défaut seulement après une gate de télémétrie et une semaine de canary.

La leçon : l’upscaler n’a pas cassé le jeu. Il a révélé une hypothèse : « les particules n’ont pas besoin de vecteurs ».
En terre temporelle, tout a besoin de vecteurs — ou vous devez dire à l’upscaler de ne pas faire confiance à l’historique.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une application de visualisation d’entreprise (pensez : proche du CAO, beaucoup de lignes fines) a intégré FSR 1 comme gain de performance rapide
sur les GPU intégrés. Quelqu’un a eu l’idée brillante d’augmenter agressivement la netteté pour faire « ressortir » les wireframes.
Les démos paraissaient nettes sur captures statiques.

En utilisation réelle, les utilisateurs panoramaient et zoomaient constamment. La netteté a amplifié l’aliasing et rendu les bords scintillants en mouvement.
Les gens se sont plaints de « fatigue oculaire » et de « clignotement », ce qui est le genre de retour sur lequel vous ne pouvez pas argumenter parce que c’est
littéralement un rapport du système nerveux humain.

L’équipe a répondu en augmentant l’échelle de rendu, ce qui a amélioré la qualité mais réduit les performances — annulant la raison d’adopter FSR 1 initialement.
Pire, la nouvelle échelle a déclenché une pression VRAM sur les systèmes bas de gamme à cause des targets de rendu plus grandes.
Désormais ils avaient du scintillement et des saccades occasionnelles.

La correction finale a été ennuyeuse : réduire la netteté, ajouter un passe anti-aliasing pour les lignes fines adapté à leur contenu,
et exposer un slider utilisateur « stabilité vs netteté » avec des valeurs par défaut sensées. Ils ont aussi documenté que FSR 1 n’est pas une baguette magique
pour l’art de lignes subpixel.

La leçon : la netteté n’est pas du détail gratuit. C’est un amplificateur de contraste. Si votre contenu est déjà sujet à l’aliasing,
la netteté est de l’essence pour le feu.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande équipe de jeu avait l’habitude, qui semblait trop procédurale : chaque fonctionnalité graphique avait un « repro pack ».
C’était un zip d’itinéraires de caméra déterministes, des paramètres d’heure fixe, et un script pour lancer des captures avec les mêmes
réglages de pilote, le même cap de frame, et le même état de cache shader.

Lorsqu’ils ont intégré un upscaler temporel (classe FSR 2), ils ont ajouté quelques scènes conçues spécifiquement pour le casser :
clôtures en chain-link, feuillage fin, particules sur fond à fort contraste, coupes rapides de caméra, et flaques réfléchissantes.
Chaque scène avait des seuils d’artefacts attendus et des motifs « connus mauvais » liés aux fautes d’intégration communes.

Des mois plus tard, une mise à jour de pilote a causé des rapports sporadiques de scintillement. L’équipe n’a pas débattu d’opinions.
Ils ont exécuté le repro pack sur deux versions de pilote, trouvé une régression isolée à une passe de post-process particulière,
et livré une petite mitigation tout en déposant un bug propre chez le fournisseur avec des captures.

Les joueurs ont vu un patch rapide. L’équipe ingénierie a évité une réécriture panique. La direction a obtenu un calendrier avec des preuves.
Et personne n’a eu à « faire confiance aux vibes » d’une capture d’écran d’un seul réviseur.

La leçon : les bancs d’essai déterministes semblent ennuyeux jusqu’au jour où ils empêchent une foire aux reproches inter-équipes.

Erreurs courantes (symptômes → cause racine → correction)

1) L’UI paraît douce ou étalée

Symptômes : Le texte HUD perd de la netteté ; la minimap paraît floue ; les sous-titres scintillent en mouvement.

Cause racine : L’UI est rendue dans la scène 3D avant l’upscaling, ou l’UI est traitée comme du contenu réutilisable par l’historique.

Correction : Rendre l’UI à la résolution de sortie après l’upscaling ; si vous devez composer plus tôt, taggez l’UI dans les masques réactifs et évitez la réutilisation de l’historique.

2) Ghosting derrière les personnages en mouvement

Symptômes : Traînées derrière joueurs/NPCs, surtout sur fonds à fort contraste.

Cause racine : Vecteurs de mouvement incorrects ou manquants pour les maillages skinning ; vecteurs dans le mauvais espace ; clamp de vélocité trop agressif.

Correction : Validez la passe de vecteurs pour l’animation skinning ; assurez-vous que les vecteurs correspondent à la projection jitterée ; ajustez le masque réactif pour les matériaux émissifs.

3) Feuillage scintillant et géométrie fine

Symptômes : Feuilles qui étincellent ; clôtures qui rampent ; fils fins qui aliasent lors des mouvements de caméra.

Cause racine : Résolution d’entrée trop basse pour le contenu ; netteté excessive ; séquence de jitter TAA instable ; mip bias trop agressif.

Correction : Utiliser un mode FSR de meilleure qualité ; réduire la netteté ; revoir le mip bias et le LOD ; assurer un jitter stable et un pondération d’historique correcte.

4) « FSR a augmenté le FPS mais le jeu semble pire »

Symptômes : Le FPS rapporté monte, mais la souris semble retardée ou incohérente.

Cause racine : Taux de base lié au CPU ; génération de frames sans contrôles de latence ; file d’attente de présentation ; réglages VRR/VSync non appariés.

Correction : Mesurez le taux de frames de base (non générées) ; capping approprié ; activer la réduction de latence si disponible ; corriger les goulets CPU/IO ; valider les graphes de pacing.

5) Saccades aléatoires après activation de l’upscaling

Symptômes : Micro-freezes toutes les quelques secondes ; pire au premier lancement ou après patch.

Cause racine : Compilation de shaders/pipeline ; IO de streaming ; overcommit de VRAM ; tâches en arrière-plan.

Correction : Réchauffez les caches de shaders en QA ; livrez des caches pipeline quand possible ; réduisez la pression VRAM via les textures ; profilez l’IO ; arrêtez les overlays en test.

6) Image « croustillante » sur-nettoyée avec reflets bruyants

Symptômes : Surfaces métalliques scintillent ; les highlights rampent ; l’image paraît granuleuse.

Cause racine : La netteté amplifie l’instabilité temporelle et l’aliasing spéculaire ; le contenu n’est pas filtré pour la basse résolution interne.

Correction : Baissez la netteté ; améliorez l’anti-aliasing spéculaire (ajustement de roughness, env maps préfiltrés) ; envisagez une échelle de rendu plus élevée.

7) Artefacts sur particules, fumée, eau et transparences

Symptômes : Fumée qui smear ; bords d’eau laissant des traînées ; particules « collées » à l’écran.

Cause racine : Les upscalers temporels peinent avec la transparence qui n’a pas de mouvement/profondeur fiable ; masques réactifs manquants.

Correction : Autorer des masques réactifs pour ces matériaux ; rendre certains effets après l’upscaling ; clamp la contribution de l’historique dans ces régions.

8) Les résultats de benchmark ne correspondent pas aux rapports des joueurs

Symptômes : Les chiffres en labo disent amélioration ; les joueurs se plaignent toujours de saccades.

Cause racine : Le chemin de benchmark évite les hotspots de streaming ; caches chaudes en labo ; réglages de pilote différents ; comportement VRR/rafraîchissement différent.

Correction : Construisez des scènes de repro déterministes incluant streaming et parcours ; suivez p99/p99.9 des temps de frame ; testez des runs cold-cache.

Listes de contrôle / plan étape par étape

Étape par étape : choisir les bons réglages par défaut FSR

1. Définir un objectif : 60 stable, 90 stable, 120+ compétitif. Ne prétendez pas qu’un seul réglage par défaut satisfait tout le monde.
2. Mesurer le goulet de base : GPU-bound vs CPU-bound en natif et en résolution réduite.
3. Sélectionner le mode le plus doux qui atteint la cible : privilégiez Quality/Balanced plutôt que Performance quand possible.
4. Définir une netteté conservatrice : commencez plus bas que vous ne le pensez ; laissez les utilisateurs augmenter si ils aiment la douleur.
5. Valider dans les pièges d’artefacts : feuillage, clôtures, particules, rotations rapides, HUD lumineux sur scènes sombres.
6. Valider le comportement au démarrage froid : compilation de shaders au premier lancement et streaming.
7. Vérifier la composition UI : assurer que l’UI est output-res et stable.
8. Documenter les limites connues : lignes fines, certaines transparences, très basse résolution d’entrée.

Checklist d’intégration : upscaling temporel de type FSR 2

• Les vecteurs de mouvement incluent : meshes skinning, corps rigides, mouvement caméra, et motion d’UV/matériaux quand applicable.
• Le buffer de profondeur correspond à la convention attendue (Z inversé, plage, linéarisation selon besoin).
• Le jitter est appliqué de manière cohérente à la couleur, profondeur et génération des vecteurs de mouvement.
• L’exposition est stable entre les frames ; les changements d’exposition abrupts réinitialisent l’historique ou réduisent le poids de l’historique.
• Des masques réactifs existent pour : particules, eau, verre transparent, panneaux émissifs, feuillage alpha-test animé.
• Les coupures de caméra et téléportations déclenchent une réinitialisation d’historique (ou logique équivalente).
• L’UI est rendue après l’upscaling (préféré) ou exclue de la réutilisation d’historique.
• Les valeurs par défaut de netteté sont conservatrices et testées en mouvement, pas seulement sur des images fixes.

Checklist opérationnelle : livrer sans se mettre en feu

• Déploiement canari pour les changements activés par défaut ; suivre les taux de plaintes par modèle GPU/fournisseur et branche pilote.
• Harnesse de régression avec scènes déterministes ; capturer distributions de temps de frame et captures d’artefacts.
• Script de support clair : quels réglages demander (mode, netteté, génération de frames, VRR, VSync).
• Matrice pilote/OS pour la QA qui reflète la réalité, pas seulement vos rigs de développement.
• Plan de secours : permettre de désactiver/switcher l’upscaler sans casser les sauvegardes ou le scaling de l’UI.

Faits intéressants & contexte historique

L’upscaling n’est pas apparu de nulle part. Voici des points de contexte concrets qui expliquent pourquoi FSR s’est imposé :

1. FSR 1 lancé en 2021, présenté comme une alternative spatiale rapide pouvant être adoptée largement sur les GPU.
2. L’attitude cross-vendor de FSR a compté : il pouvait tourner sur du hardware concurrent, ce qui a réduit la friction d’adoption pour les studios PC.
3. Le sur-échantillonnage temporel existait avant FSR dans de nombreux moteurs comme reconstruction basée TAA ; FSR 2 a formalisé une voie de haute qualité fournie par le vendeur.
4. FSR 2 a déplacé la conversation des « astuces de netteté » vers « donnez-moi des vecteurs de mouvement corrects », mettant en lumière la correction du moteur.
5. L’upscaling est lié à l’adoption du ray tracing : le coût du RT a poussé plus de titres vers des techniques de reconstruction pour rester jouables.
6. FSR 3 a apporté la génération de frames à l’écosystème AMD, élargissant la discussion vers la latence et le pacing plutôt que le simple débit.
7. Les approches ouvertes, basées sur des shaders ont permis aux développeurs d’inspecter et d’adapter les détails d’intégration plus facilement que des solutions boîte noire.
8. Les attentes console→PC ont poussé la mentalité « mode performance » dans les menus PC, normalisant le scaling de résolution interne.
9. Maturité du pilote et du compilateur influence fortement les résultats : deux systèmes avec « le même GPU » peuvent produire des profils de saccade différents selon les branches de pilote.

FAQ

1) FSR est-il du « vrai 4K » ?

Non. FSR rend à une résolution interne plus basse et reconstruit vers la résolution de sortie. L’objectif est « semble suffisamment proche à distance de vision normale » ,
pas une équivalence pixel par pixel.

2) Pourquoi FSR paraît-il parfois flou ?

Généralement parce que la résolution d’entrée est trop basse pour la complexité de la scène, la netteté est faible, ou la chaîne de post-traitement du jeu n’est pas compatible
avec la reconstruction (grain filmique, DOF agressif, motion blur).

3) Pourquoi FSR paraît-il parfois trop net ou bruyant ?

La sur-netteté amplifie l’aliasing et l’instabilité temporelle. Réduisez la netteté en premier. Si les highlights spéculaires rampent, vous pourriez aussi avoir besoin d’un meilleur
anti-aliasing spéculaire dans le contenu/shaders.

4) Quelle est la différence pratique entre FSR 1 et FSR 2 ?

FSR 1 est spatial : rapide et simple, peu d’exigences d’intégration, reconstruction de détail plus faible. FSR 2 est temporel : potentiel qualité plus élevé,
mais dépend de vecteurs de mouvement corrects, profondeur, jitter et gestion d’historique.

5) FSR aide-t-il si je suis lié CPU ?

Pas beaucoup. Réduire la résolution interne diminue le travail GPU, mais si le CPU limite la frame, les gains peuvent être faibles.
Diagnostiquez CPU vs GPU avant d’attendre des miracles.

6) Pourquoi la génération de frames semble parfois lente ?

Parce que générer des frames affichées supplémentaires ne réduit pas automatiquement la latence d’entrée. Si le taux de base est bas ou instable,
vous pouvez obtenir un mouvement plus fluide avec une réponse d’entrée similaire ou pire.

7) Quel est le meilleur mode FSR par défaut ?

Pour la plupart des titres : commencez par Quality (ou Balanced à hautes résolutions) et une netteté conservatrice. « Performance » est pour quand vous en avez vraiment besoin,
et après avoir testé la géométrie fine et le feuillage soigneusement.

8) Pourquoi les particules et effets transparents sont-ils pires avec l’upscaling temporel ?

Les transparences ne se comportent pas comme la géométrie solide en termes de mouvement/profondeur. Sans masques réactifs ou traitement spécial, l’upscaler réutilise mal l’historique
et vous voyez du smear ou du ghosting.

9) Activer FSR réduit-il l’utilisation VRAM ?

Cela peut réduire certaines tailles de render target, mais les textures, buffers de géométrie et structures ray tracing dominent souvent la VRAM.
Si vous êtes proche de la limite VRAM, réduisez les textures et les caches d’ombres avant d’espérer que l’upscaling règle les hitchs.

Conclusion : prochaines étapes pratiques

FSR n’a pas seulement rendu l’upscaling populaire. Il l’a rendu opérationnellement normal : un réglage que les joueurs attendent, que les testeurs évaluent,
et sur lequel les studios comptent pour atteindre des objectifs de performance sans sacrifier l’esthétique.
C’est la bonne nouvelle. La mauvaise nouvelle est que la reconstruction temporelle punit les entrées de moteur bâclées.

Si vous déployez ou supportez FSR dans le monde réel, faites ceci ensuite :

1. Arrêtez d’utiliser le FPS moyen comme étoile polaire. Suivez p95/p99 des temps de frame et la cohérence du pacing.
2. Construisez un pack de repro déterministe avec des scènes qui stressent volontairement la reconstruction temporelle.
3. Validez les vecteurs de mouvement et les masques avant de toucher aux valeurs par défaut de netteté.
4. Séparez les gains GPU-bound des problèmes CPU/IO. L’upscaling ne résoudra pas la compilation de shaders ou le streaming lent.
5. Livrez des valeurs par défaut sensées et des bascules claires. Permettez aux utilisateurs de se désengager proprement quand leur configuration est l’exception.

L’upscaling fait désormais partie du contrat de base entre votre renderer et vos joueurs. Traitez-le comme n’importe quelle autre dépendance de production :
mesurez-le, testez-le, et ne lui faites pas confiance tant qu’il n’a pas gagné votre confiance.