Si vous avez déjà déployé une fonctionnalité graphique « qui marche sur ma machine » sur une flotte de PC très différents, vous connaissez déjà la sensation :
une mise à jour de pilote qui suffit pour semer le chaos, un réglage ambitieux qui transforme les images en 45 ms par frame, et une base d’utilisateurs qui va absolument
mesurer en permanence votre pire scène.
Le ray tracing (RT) est arrivé exactement dans cette réalité opérationnelle. Pour AMD, « rattraper son retard » n’était pas un problème d’image ; c’était une décision de
séquençage basée sur la gestion des risques. En termes de production : obtenir d’abord la correction, la compatibilité et des performances prévisibles—puis étendre les effets avancés.
Pourquoi « rattraper son retard » était le choix intelligent
Dans la tech, « rattraper son retard » est souvent utilisé comme une insulte par des personnes qui n’ont jamais eu à piloter une feuille de route avec des contraintes :
budget énergétique, surface de die, temps de vérification, maturité de l’écosystème logiciel, parité console, et la délicieuse réalité que
les jeux sont livrés par des studios avec des échéances, pas par des théoriciens devant un tableau blanc.
La décision d’AMD d’entrer dans le ray tracing matériel plus tard—et de manière plus conservatrice—a du sens quand on considère les GPU comme des systèmes de production.
Un GPU n’est pas une seule fonctionnalité. C’est une pile : ISA, caches, contrôleurs mémoire, ordonnancement, firmware, pilotes, compilateurs de shaders,
API OS, moteurs de jeu et pipelines de contenu. Le RT met presque tout cela à l’épreuve en même temps.
« Rattraper son retard » signifie laisser quelqu’un d’autre prendre la première vague d’inconnues : les bords initiaux d’API, les bugs d’intégration moteur,
les nouvelles erreurs d’authoring de contenu (les matériaux mal conçus explosent dans les path-tracers), la stabilité des pilotes sous des motifs de shader inédits,
et les falaises de performance étranges qui arrivent quand les structures d’accélération rencontrent des scènes réelles.
Le choix intelligent n’est pas « livrer le RT d’abord ». Le choix intelligent est :
- Livrer le RT quand votre pile logicielle peut le supporter (pilote, compilateur, outils, couverture QA).
- Livrer le RT quand le marché en a besoin (consoles, moteurs, adoption par les développeurs).
- Livrer le RT sans dégrader la rasterisation (parce que la plupart des pixels sont encore rasters).
- Livrer le RT avec une stratégie d’upscaling (car le RT brut est une taxe de performance).
Du point de vue SRE, AMD a optimisé pour la fiabilité et des résultats prévisibles sur une large base installée, pas seulement pour le tableau des meilleurs scores.
Ce n’est pas de la lâcheté. C’est de l’opérationnel.
Blague n°1 : Le ray tracing, c’est comme l’observabilité—une fois activé, vous découvrez immédiatement combien de choses vous ne vouliez pas savoir.
Faits et contexte historique qui comptent vraiment
Voici des points concrets (pas des anecdotes) qui expliquent pourquoi la stratégie de « rattrapage » d’AMD était rationnelle :
- Le RT était « offline » pendant des décennies : les pipelines film/VFX utilisaient le ray tracing bien avant que les GPU temps réel ne puissent, car ils échangeaient le temps contre la qualité.
- DXR a formalisé une API mainstream : DirectX Raytracing a fait du « RT comme pipeline » une norme, pas une démo fournisseur.
- Les structures d’accélération BVH sont le véritable cheval de trait : un RT rapide dépend de la construction et de la traversée efficaces des BVH ; ce n’est pas juste « ajouter des cœurs RT ».
- Le RT temps réel précoce était hybride : presque tous les jeux commercialisés utilisent raster + effets RT limités (ombres, réflexions, AO) plutôt que du path tracing complet.
- Les consoles ont compté : les consoles équipées d’AMD ont apporté du hardware RT à une plate-forme fixe massive, poussant les moteurs à traiter le RT comme une vraie fonctionnalité.
- L’upscaling est devenu partie prenante du RT : des techniques style DLSS/FSR ont transformé « trop lent » en « peut être livré » en échangeant résolution contre reconstruction temporelle.
- La maturité pilote/compilateur est un avantage compétitif : les charges RT sollicitent les compilateurs de shaders et l’allocation de registres différemment que la rasterisation classique.
- La performance RT est souvent liée à la mémoire/la latence : la traversée peut être incohérente ; les caches ratent ; la latence mémoire devient le tueur silencieux.
- La cohérence du temps de frame bat le pic de FPS : le stutter dû à la compilation de shader ou aux rebuilds de BVH est ce que les joueurs ressentent et ce qui remplit les tickets de support.
Ce que le ray tracing coûte vraiment : taxonomie des goulots d’étranglement
1) Coût de construction/mise à jour des structures d’accélération (BVH)
Le RT ne commence pas par les rayons. Il commence par les structures de données. Le BVH (ou équivalent) doit être construit ou mis à jour pour la géométrie.
Les scènes dynamiques—personnages animés, objets destructibles, props mobiles—ajoutent un coût de construction/mise à jour, et ce coût peut varier par frame.
En termes opérationnels : le travail BVH est un job en batch variable sur votre chemin critique. Si vous ne le bornez pas, il vous réveillera à 2 h du matin
sous forme de rapports de stutter aléatoires.
2) Incohérence de traversée et de shading
La rasterisation a de la cohérence : les pixels voisins vont souvent chercher des textures similaires, suivre des flux de contrôle similaires, toucher une géométrie similaire.
Le RT peut détruire cela : les rayons rebondissent vers des parties non liées de la scène. Ça veut dire divergence dans l’exécution des shaders et une très mauvaise localité de cache.
C’est pourquoi « plus de calcul » ne corrige pas linéairement le RT. Parfois vous attendez la mémoire. Parfois vous attendez des caches manqués.
Parfois vous attendez une exécution divergente parce que la moitié de la wavefront a pris une branche différente.
3) Dénombrement et accumulation temporelle (denoising)
Le RT temps réel utilise souvent peu de rayons par pixel. Sans denoising, vous obtenez un rendu scintillant.
Les débruiteurs sont des charges de calcul avec leur propre comportement bande passante et cache. Ils introduisent aussi des problèmes de stabilité temporelle :
fantômes, traînées et la douleur particulière du « ça paraît bien en mouvement, ça casse quand vous vous arrêtez ».
4) Surcharge pilote et compilation de pipeline
Les pipelines RT peuvent augmenter le nombre de variantes de shaders et la complexité de compilation. Si vous tombez sur une compilation au runtime—ou pire, si vous livrez sans cache de shaders chaud—
votre bug « le RT est lent » est en fait un incident « vous avez compilé un shader en plein combat ».
5) La taxe cachée : l’empreinte mémoire
Les BVH coûtent de la mémoire. Des G-buffers supplémentaires coûtent de la mémoire. Des effets RT de meilleure qualité signifient plus de buffers intermédiaires.
Quand la pression VRAM augmente, vous voyez évictions, pagination et des pics soudains du temps de frame.
L’approche RT d’AMD : ingénierie pragmatique, pas du style
L’entrée d’AMD dans le RT avec RDNA2 ressemblait à un compromis pratique : ajouter un support matériel (Ray Accelerators par CU) tout en gardant
une architecture globale équilibrée pour la rasterisation et les contraintes console.
C’est la clé : AMD n’a pas construit un GPU qui est « un appareil RT qui sait aussi rasteriser ».
Ils ont construit des GPU qui restent fondamentalement raster-first, parce que la plupart du contenu l’est encore.
Le « rattrapage » est volontairement contraint par la réalité : coût, puissance, rendement, et compatibilité large.
Si vous gérez des systèmes de production, vous reconnaissez le schéma. Vous ne reconstruisez pas toute la plateforme pour supporter une nouvelle fonctionnalité.
Vous faites fonctionner la fonctionnalité dans l’enveloppe opérationnelle existante. Puis vous itérez.
AMD avait aussi une ancre stratégique différente : les consoles. Quand votre architecture est dans des consoles, vous optimisez pour :
pilotes stables, comportement mémoire prévisible, et performance par watt dans un boîtier thermique fixe.
Cela tend à produire des choix conservateurs et évolutifs plutôt que « jette des transistors sur le problème et prie ».
Voici la vérité inconfortable : l’adoption précoce du RT fut en partie un problème de relations développeurs. Si les moteurs ne publient pas largement des chemins RT,
le RT matériel reste une case brillante. Une fois que les consoles ont rendu le RT plus courant, le timing d’AMD a semblé moins « tardif » et plus « aligné ».
Mesurer d’abord : quoi collecter avant d’« optimiser »
La façon la plus rapide de perdre des semaines est de débattre des performances RT sur la base de captures d’écran FPS moyennes.
Vous voulez des distributions de temps de frame, des splits CPU/GPU, la marge VRAM, et le comportement de compilation des shaders.
Un workflow fiable :
- Commencez par une scène reproductible : même trajectoire de caméra, même point de sauvegarde, même météo/heure, même état des PNJ si possible.
- Capturez les temps de frame, pas seulement le FPS.
- Séparez les cas limités par le CPU de ceux limités par le GPU.
- Testez les effets RT individuellement (réflexions vs ombres vs GI) et enregistrez les deltas.
- Surveillez la pression VRAM et la RAM système.
- Validez le comportement du cache de shaders après les mises à jour de pilotes.
Citation (idée paraphrasée) : Werner Vogels a popularisé l’idée que vous devriez construire des systèmes en attendant des pannes, et concevoir pour la résilience plutôt que la perfection.
— Werner Vogels (idée paraphrasée)
Tâches pratiques : commandes, sortie, signification, décision
Ces tâches sont écrites comme si vous étiez en astreinte et aviez besoin de réponses, pas d’impressions subjectives. Elles penchent vers Linux parce que c’est scriptable et honnête,
mais les principes s’appliquent ailleurs. Chaque tâche inclut : commande, sortie d’exemple, ce que ça signifie, et quelle décision prendre.
Task 1: Identify the GPU and driver stack
cr0x@server:~$ lspci -nn | grep -E "VGA|3D"
0b:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [1002:744c]
What it means: You’re confirming the actual GPU (and PCI ID), not what marketing slides say.
Decision: If the device doesn’t match the target (RDNA2 vs RDNA3), stop. Your “RT regression” might be “wrong host.”
Task 2: Confirm kernel driver and Mesa/AMDGPU versions
cr0x@server:~$ uname -r
6.5.0-21-generic
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 7900 XTX (navi31, LLVM 16.0.6, DRM 3.54, 6.5.0-21-generic) (0x744c)
Version: 23.2.1
What it means: RT performance and stability are extremely driver/compiler sensitive. This identifies the stack.
Decision: If you’re on an old Mesa/driver and complaining about RT, you may be benchmarking archaeology.
Task 3: Verify Vulkan ray tracing extensions are present
cr0x@server:~$ vulkaninfo --summary | sed -n '1,80p'
Vulkan Instance Version: 1.3.275
Devices:
========
GPU0:
apiVersion = 1.3.275
deviceName = AMD Radeon RX 7900 XTX
driverVersion = 2.0.279
deviceType = DISCRETE_GPU
Device Extensions: count = 182
VK_KHR_acceleration_structure
VK_KHR_ray_tracing_pipeline
VK_KHR_deferred_host_operations
What it means: The Vulkan RT path is available. If these extensions are missing, the game/engine will silently fall back.
Decision: Missing extensions means you debug driver packaging or environment, not “RT performance.”
Task 4: Check GPU clocks and power state (to catch “stuck in low power”)
cr0x@server:~$ cat /sys/class/drm/card0/device/pp_dpm_sclk
0: 500Mhz
1: 1500Mhz
2: 2400Mhz *
What it means: The asterisk shows the current performance level.
Decision: If you’re stuck at low clocks under RT load, your issue is power management/thermals, not RT cores.
Task 5: Spot thermal throttling signals
cr0x@server:~$ cat /sys/class/drm/card0/device/hwmon/hwmon*/temp1_input 2>/dev/null | head -n 1
78000
What it means: Temperature in millidegrees Celsius (78°C here). RT loads can shift power distribution and cause hotspots.
Decision: If temps are high and clocks drop, fix cooling or power limits before changing settings.
Task 6: Check VRAM usage and eviction pressure (quick signal)
cr0x@server:~$ cat /sys/kernel/debug/dri/0/amdgpu_vram
VRAM size: 24576M
VRAM used: 21234M
GTT size: 32768M
GTT used: 6120M
What it means: You’re close to VRAM full; spills to GTT (system memory) can spike frame times.
Decision: Reduce texture resolution/RT quality, or increase headroom by closing apps. If VRAM is near cap, stop chasing shader tweaks.
Task 7: Detect CPU bottleneck vs GPU bottleneck with MangoHud
cr0x@server:~$ mangohud --dlsym ./game_binary
... MangoHud: GPU 98% CPU 35% frametime 21.3ms fps 47 ...
What it means: GPU is saturated. If CPU were pegged and GPU low, you’d be CPU-limited.
Decision: GPU-bound: tune RT settings, resolution, denoiser. CPU-bound: reduce draw calls, improve threading, or lower simulation cost.
Task 8: Capture frame time distribution (not average FPS)
cr0x@server:~$ cat frametimes.csv | awk -F, 'NR>1{sum+=$2; if($2>p99) p99=$2} END{print "max_ms="p99, "avg_ms="sum/(NR-1)}'
max_ms=78.1 avg_ms=19.6
What it means: A single 78 ms spike is user-visible stutter even if average is fine.
Decision: If max/p95/p99 frame times are bad, prioritize stutter sources: shader compilation, paging, BVH rebuild, CPU spikes.
Task 9: Verify shader cache directories exist and are writable
cr0x@server:~$ ls -ld ~/.cache/mesa_shader_cache
drwx------ 12 cr0x cr0x 4096 Jan 13 09:12 /home/cr0x/.cache/mesa_shader_cache
What it means: If shader cache can’t persist, you’ll recompile constantly and get “random” hitching.
Decision: If permissions are wrong or cache is on a slow filesystem, fix that first.
Task 10: Check for runtime shader compilation spikes in logs (example pattern)
cr0x@server:~$ journalctl --user -n 200 | grep -i -E "shader|pipeline|compile" | tail -n 5
Jan 13 09:22:41 gamehost game_binary[8123]: vkCreateRayTracingPipelinesKHR: compiling pipeline cache miss
Jan 13 09:22:41 gamehost game_binary[8123]: stutter-warning: pipeline compilation took 145ms
What it means: Pipeline compilation happened on the critical path.
Decision: Precompile pipelines, ship a pipeline cache, or restructure to compile async before the scene needs it.
Task 11: Check PCIe link speed (a classic “why is streaming awful?” culprit)
cr0x@server:~$ sudo lspci -s 0b:00.0 -vv | grep -E "LnkCap|LnkSta"
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16
What it means: You’re at expected PCIe speed/width. If it drops (x4 or lower), streaming and uploads can stall.
Decision: If link is degraded, reseat the GPU, fix BIOS settings, or move slots before blaming RT.
Task 12: Detect memory pressure and swapping (stutter amplifier)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 32Gi 28Gi 1.2Gi 1.0Gi 2.8Gi 2.1Gi
Swap: 8.0Gi 2.1Gi 5.9Gi
What it means: You’re swapping. RT + high-res textures can push system memory too, especially with background apps.
Decision: Close memory hogs, increase RAM, reduce texture settings, or fix leaks. Swapping makes everything look like an RT issue.
Task 13: Inspect I/O latency for shader cache and asset streaming
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
18.21 0.00 4.12 6.70 0.00 70.97
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await wareq-sz aqu-sz %util
nvme0n1 58.0 4120.0 0.0 0.0 1.20 71.0 42.0 2048.0 9.80 48.8 0.55 62.0
What it means: Write await is high (9.8 ms). If your shader cache sits on a slow or busy disk, you’ll see hitching.
Decision: Move cache to faster storage, reduce background I/O, or fix filesystem mount options.
Task 14: Confirm filesystem behavior for cache (noatime reduces useless writes)
cr0x@server:~$ mount | grep " /home "
/dev/nvme0n1p2 on /home type ext4 (rw,noatime,errors=remount-ro)
What it means: noatime avoids updating access times on reads, reducing metadata churn.
Decision: If your cache directory lives on a mount with heavy metadata updates, consider tuning. It’s not glamorous, but it’s measurable.
Task 15: Validate that RT toggles actually change GPU work
cr0x@server:~$ grep -E "rt_enabled|rt_reflections|rt_shadows" ~/.config/game/settings.ini
rt_enabled=1
rt_reflections=0
rt_shadows=1
What it means: You’d be shocked how often UI toggles don’t apply until restart, or are overridden by presets.
Decision: If toggles don’t persist, stop A/B testing until you fix the config pipeline.
Task 16: Quick sanity test: raster-only baseline vs RT-on delta
cr0x@server:~$ ./bench_scene.sh --preset raster --runs 3
run1 avg_fps=124 p99_ms=11.3
run2 avg_fps=122 p99_ms=11.9
run3 avg_fps=123 p99_ms=11.6
cr0x@server:~$ ./bench_scene.sh --preset rt_medium --runs 3
run1 avg_fps=68 p99_ms=24.8
run2 avg_fps=66 p99_ms=26.1
run3 avg_fps=67 p99_ms=25.4
What it means: RT adds both a throughput hit (FPS) and a tail-latency hit (p99).
Decision: If p99 worsens more than average, focus on spikes (BVH rebuild, cache misses, compilation) before chasing raw speed.
Blague n°2 : Activer les réglages RT ultra pour « tester la stabilité » revient à tester la charge d’une base de données en y mettant le feu—techniquement informatif, émotionnellement coûteux.
Mode d’action pour un diagnostic rapide
C’est le workflow « vous avez 30 minutes avant la réunion ». Il est ordonné pour isoler d’abord les plus gros postes.
First: prove what you are running
- Confirmez GPU + pile pilote (Task 1–2). Si vous ne pouvez pas le nommer, vous ne pouvez pas le corriger.
- Confirmez le chemin API : DXR/extensions Vulkan RT présentes (Task 3). Pas d’extensions, pas de chemin RT.
- Confirmez que les réglages sont appliqués (Task 15). L’interface ment ; les fichiers de config le font rarement.
Second: classify the bottleneck (CPU, GPU, memory, I/O)
- Limitation GPU vs CPU (Task 7). Cela détermine si vous ajustez les réglages ou les threads.
- Marge VRAM (Task 6). Si vous êtes proche du plein, « le RT est lent » peut être « la pagination est lente ».
- Swap système (Task 12). La pagination rend les queues de frame hideuses.
- Latence stockage (Task 13). Les accrochages shader/asset peuvent être de l’I/O, pas du GPU.
Third: hunt spikes, not averages
- Distribution des temps de frame (Task 8). p95/p99 sont la vérité.
- Preuves de compilation shader/pipeline (Task 10, Task 9). Corrigez le caching et la stratégie de précompilation.
- Thermique/état des clocks (Task 4–5). Si les clocks chutent, vous perdez la course avant même de commencer.
Fourth: only then tune RT
- Désactivez un effet RT à la fois (ombres, réflexions, GI).
- Réduisez le nombre de rebonds et la distance des rayons.
- Préférez des presets de denoiser stables plutôt que des réglages agressifs qui scintillent.
- Utilisez l’upscaling intelligemment ; ne considérez pas le RT natif 4K comme un mérite moral.
Trois mini-histoires d’entreprise (de celles dont on apprend)
Mini-histoire 1 : L’incident causé par une mauvaise hypothèse
Un studio de taille moyenne a livré un patch RT pour un titre multiplateforme. Ils ont testé sur quelques GPU haut de gamme, vu de bons moyennes,
et déclaré victoire. Les tickets de support sont arrivés comme la pluie : « le RT cause du stutter chaque fois que j’entre dans une nouvelle zone. »
La mauvaise hypothèse était simple : ils ont supposé que « la compilation de shader se produit pendant les écrans de chargement ».
Dans leur intégration moteur, les variantes de pipeline RT pour certains matériaux n’étaient demandées que la première fois qu’une combinaison spécifique
de lumières et de surfaces apparaissait. Ça s’est produit en cours de partie.
Sur certains systèmes, le dossier du cache de shaders se trouvait sur un SSD SATA lent et presque plein. Sur d’autres, il était dans un dossier personnel synchronisé sur le réseau.
La compilation elle-même était coûteuse ; les écritures de cache empirent la situation. Les joueurs ne voyaient pas un jeu lent. Ils voyaient un jeu incohérent.
La correction n’était pas un réglage magique du RT. C’était de la discipline opérationnelle : livrer un cache de pipelines préchauffé, compiler à l’avance pendant
des transitions connues, et journaliser les manques de cache avec assez de contexte pour les reproduire. Ils ont aussi ajouté une option pour exécuter un passage de « préchauffage des shaders »
après les mises à jour de pilotes.
Leur plus grand gain fut culturel : l’équipe a arrêté d’utiliser le FPS moyen comme critère de sortie et a commencé à utiliser des seuils de temps de frame p99 par scène.
Les plaintes de stutter ont fortement diminué, même si le FPS moyen avait à peine changé.
Mini-histoire 2 : L’optimisation qui s’est retournée contre eux
Une équipe graphique interne a essayé « d’optimiser les réflexions RT » en augmentant la longueur des rayons et en réduisant le nombre d’échantillons,
en comptant sur le débruiteur pour combler les lacunes. Sur le papier : moins de rayons, frame plus rapide.
En pratique, les rayons plus longs tapaient plus de géométrie, causaient plus d’étapes de traversée, et produisaient des entrées plus bruyantes pour le débruiteur.
Le débruiteur a alors nécessité plus d’accumulation temporelle pour se stabiliser. Cela a introduit du ghosting lors de mouvements rapides de caméra.
L’équipe a répondu par plus de passes de débruitage. L’utilisation GPU a augmenté, pas diminué. Pire : la bande passante mémoire a grimpé, car le débruiteur
déplaçait beaucoup de données entre plusieurs buffers. Sur certaines cartes AMD, la charge est devenue plus sensible au comportement du cache et a montré de plus gros pics p99.
Ils ont fait marche arrière et pris l’approche ennuyeuse mais correcte : rayons plus courts, un peu plus d’échantillons, et un preset de débruiteur conçu pour la stabilité.
Les performances n’ont pas « brillé » sur une slide, mais le jeu se ressentait mieux et produisait moins d’artéfacts limites.
La leçon : les « optimisations » RT qui augmentent la variance sont de la dette opérationnelle. Si vous ne pouvez pas la prédire, vous ne pouvez pas la livrer en sécurité.
Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une équipe plateforme maintenait un laboratoire de machines GPU de test. Pas glamour. Surtout des câbles, des étiquettes, et un tableur.
Mais ils faisaient respecter une politique : chaque run de performance journalise la version du pilote, la version du kernel, le hash du build du jeu, le fichier de config, et une trajectoire de caméra fixe.
Lors d’une mise à jour majeure, quelqu’un a signalé « le RT est 20 % plus lent sur AMD maintenant. » Internet aurait pris ça et couru se planter contre un mur.
Le labo ne l’a pas fait. Ils ont relancé le même test avec la même trajectoire de caméra, puis comparé les stacks de pilotes.
La régression a été corrélée à une mise à jour du pilote qui changeait le comportement du compilateur de shaders. Le build du jeu n’avait pas changé.
L’équipe l’a reproduite sur plusieurs machines, capturé des traces, et remis au fournisseur un paquet de repro serré.
Pendant ce temps, ils ont livré une mesure d’atténuation : un changement mineur de contenu qui réduisait la divergence matérielle pire-cas dans la passe RT,
plus un ajustement de preset par défaut qui a récupéré du temps dans la queue de latence. Les utilisateurs ont vu une amélioration rapidement.
La pratique ennuyeuse—métadonnées de test structurées et reproductibilité—a transformé une tempête de blâme potentielle en un ticket d’ingénierie résoluble.
Ça n’a pas fait la une. Ça a sauvé la sortie.
Erreurs courantes : symptôme → cause racine → correction
Cette section est volontairement spécifique. Ce sont les modes de défaillance qui font perdre du temps aux vraies équipes.
1) Symptom: RT “kills FPS” but GPU utilization is low
Root cause: CPU-bound frame, often from increased draw calls, BVH build on CPU, or poor threading.
Fix: Reduce CPU-side work (culling, batching), move BVH work to GPU where applicable, profile threads, and validate you’re not compiling pipelines on the main thread.
2) Symptom: Microstutter when entering new areas
Root cause: Runtime pipeline/shader compilation and cache misses; asset streaming stalls.
Fix: Precompile pipelines, warm shader caches, move cache to fast local storage, and stage assets earlier.
3) Symptom: Smooth average FPS, ugly p99 spikes
Root cause: VRAM eviction, BVH rebuild spikes, background I/O, or periodic OS tasks.
Fix: Ensure VRAM headroom, reduce RT buffer counts, cap BVH update cost, and isolate test environment from background load.
4) Symptom: RT reflections look “sparkly” or unstable
Root cause: Too few rays per pixel, overly aggressive denoiser settings, or mismatched motion vectors.
Fix: Increase sample count slightly, tune ray distance, verify motion vectors, and choose denoiser settings that prioritize temporal stability.
5) Symptom: After driver update, RT performance changes dramatically
Root cause: Shader compiler changes and invalidated caches; different register allocation and wave occupancy.
Fix: Rebuild shader caches, rerun baselines, and treat drivers as part of your release matrix.
6) Symptom: RT-on causes crashes or device lost under load
Root cause: Unbounded VRAM usage, too-large acceleration structures, or driver/firmware bugs triggered by rare shaders.
Fix: Add guardrails: cap geometry in RT pass, reduce RT resolution, validate memory allocations, and build minimal repros.
7) Symptom: RT seems worse on one vendor “for no reason”
Root cause: Vendor-specific shader patterns, divergence sensitivity, or reliance on an upscaler feature with different behavior.
Fix: Use vendor-neutral profiling, test with equivalent upscaling presets, and avoid assumptions about how traversal is accelerated.
Listes de contrôle / plan étape par étape
Checklist A: If you’re buying/choosing hardware for RT workloads
- Définir l’objectif : verrouillé 60 fps, compétitif 120 fps, ou « cinématique 40 fps ». Ne faites pas semblant que ce sont les mêmes besoins.
- Choisir des scènes qui correspondent à votre charge réelle : feuillages, foules, intérieurs réfléchissants, néons nocturnes—tous stressent le RT différemment.
- Mesurer p95/p99 du temps de frame, pas seulement les moyennes.
- Planifier une marge VRAM (au moins quelques Go) pour les buffers RT et les patches futurs.
- Décider de votre politique d’upscaling à l’avance (FSR/DLSS/natif). Le RT sans upscaling est une taxe de luxe.
- Valider la maturité des pilotes pour votre OS et version moteur.
Checklist B: If you’re a studio shipping RT on AMD (and everyone else)
- Construire un chemin de benchmark reproductible (trajectoire de caméra fixe, seed fixe, fichier de réglages fixe).
- Livrer un chemin de préchauffage shader/pipeline et journaliser les manques de cache.
- Exposer les fonctionnalités RT comme des basculements indépendants (ombres/réflexions/GI) et garder des presets sensés.
- Limiter le coût de construction/mise à jour des structures d’accélération par frame ; différer les mises à jour non critiques.
- Privilégier le débruitage stable plutôt que des astuces low-sample agressives qui scintillent.
- Tester explicitement la pression VRAM : « presque plein » doit être un mode de test séparé.
- Maintenir une matrice de pilotes et relancer les baselines après les changements de pilotes.
- Faire du « p99 frame time » un critère de sortie pour les presets RT.
Checklist C: If you’re troubleshooting “RT is slow” as an operator
- Confirmer le matériel et la pile pilote (Tasks 1–2).
- Confirmer la disponibilité de l’API RT (Task 3).
- Classer le goulot (Task 7, 6, 12, 13).
- Mesurer les queues de temps de frame (Task 8, 16).
- Rechercher la compilation (Task 10) et les problèmes de cache (Task 9).
- Vérifier les thermiques et les clocks (Tasks 4–5).
- Ce n’est qu’ensuite que vous devez tuner les réglages RT ; ne faites pas d’ajustements à l’aveugle.
FAQ
1) Is AMD “bad at ray tracing”?
Non. Les performances RT d’AMD dépendent fortement du jeu, de l’intégration dans le moteur et des réglages. Plus une charge est liée à la latence mémoire et divergente,
plus les différences d’architecture se manifestent. Considérez cela comme un problème d’adéquation de charge, pas une question de morale.
2) Why does RT feel worse than raster even when FPS looks okay?
Parce que le RT aggrave souvent la latence en queue. Les temps de frame p99 importent plus pour la perception de fluidité que le FPS moyen.
Les pics viennent de la compilation, des rebuilds de BVH et de la pression mémoire.
3) Why do reflections cost so much more than shadows sometimes?
Les réflexions nécessitent souvent des rayons plus longs, un shading plus complexe et des impacts plus incohérents. Les ombres peuvent être moins coûteuses si elles sont
limitées en portée et en simple rebond.
4) Should I always enable upscaling with RT?
Dans la plupart des titres temps réel, oui. L’upscaling fait partie du budget performance RT. Tournez à une résolution interne plus basse et dépensez
le temps économisé sur des effets RT et un débruiteur stable.
5) What’s the biggest “gotcha” in RT performance testing?
Le cache shader et la compilation de pipeline. Si votre première exécution inclut une compilation et la seconde non, vous n’avez pas benchmarké le RT ;
vous avez benchmarké votre pipeline de build.
6) Why can a driver update change RT performance so much?
Les pipelines shader RT sollicitent les compilateurs différemment : allocation de registres, ordonnancement et occupancy peuvent changer.
De plus, les mises à jour de pilotes peuvent invalider les caches, causant du stutter au premier run.
7) What should studios prioritize: peak FPS or frame time consistency?
La cohérence. Un 60 fps stable avec un bon p99 se ressent mieux qu’une moyenne de 90 fps avec des pics réguliers à 40 ms.
La stabilité réduit aussi la charge de support et les reviews négatives.
8) Does “more RT hardware” automatically mean better RT?
Pas automatiquement. La traversée et le shading peuvent être limités par la latence mémoire, le comportement des caches, la divergence et le coût du denoiser.
Le hardware aide, mais la charge et la pile logicielle décident du résultat.
9) If I’m GPU-bound with RT on, what setting usually gives the best win?
Réduire la résolution RT (souvent via un mode d’upscaling), puis réduire la distance des rayons et le nombre de rebonds.
Désactiver l’effet RT le plus coûteux (souvent réflexions/GI) peut récupérer énormément de temps de frame.
Prochaines étapes pratiques
Si vous retenez une chose de l’histoire RT d’AMD, retenez ceci : le séquençage compte. Livrer le RT plus tard avec une pile robuste n’est pas un échec ;
c’est un compromis discipliné entre ambition fonctionnelle et correction opérationnelle.
Faites ceci ensuite, dans l’ordre :
- Arrêtez de vous disputer sur le FPS moyen. Collectez p95/p99 des temps de frame et prenez vos décisions à partir des queues.
- Construisez un chemin de benchmark RT reproductible et journalisez la pile complète : pilote, kernel, hash du build, réglages.
- Préservez une marge VRAM. Si vous êtes à quelques Go de la limite, votre prochain patch générera du stutter.
- Corrigez le comportement de compilation des shaders/pipelines. Chauffez les caches, précompilez, et gardez le thread principal propre.
- Réglez le RT comme un opérateur : isolez une variable à la fois, mesurez les deltas, et privilégiez la stabilité plutôt que des gains fragiles.
« Rattraper son retard » est ce que vous appelez quand vous regardez seulement la course. Quand vous gérez le système, vous appelez ça de la gestion des risques.