If you’ve ever shipped a “works on my machine” graphics feature to a fleet of wildly different PCs, you already know the feeling:
one driver update away from chaos, one ambitious setting away from 45 ms frames, and a user base that will absolutely benchmark your
worst scene forever.
Ray tracing (RT) landed in exactly that operational reality. For AMD, “catching up” wasn’t a branding problem; it was a risk-managed
sequencing decision. In production terms: get correctness, compatibility, and predictable performance first—then scale the fancy stuff.
Why “catching up” was the smart play
In tech, “catching up” is often used as an insult by people who have never had to run a roadmap under constraints:
power budget, die area, verification time, software ecosystem maturity, console parity, and the delightful reality that
games are shipped by studios with deadlines, not by theorists with whiteboards.
AMD’s decision to enter hardware ray tracing later—and in a more conservative way—makes sense when you treat GPUs like production systems.
A GPU is not one feature. It’s a stack: ISA, caches, memory controllers, scheduling, firmware, drivers, shader compilers,
OS APIs, game engines, and content pipelines. RT stresses almost all of it at once.
“Catching up” means you can let someone else take the first wave of unknown-unknowns: early API edges, engine integration bugs,
new content authoring mistakes (bad materials explode in path tracers), driver stability under novel shader patterns,
and the weird perf cliffs that happen when acceleration structures meet real-world scenes.
The smart play is not “ship RT first.” The smart play is:
- Ship RT when your software stack can survive it (driver, compiler, tools, QA coverage).
- Ship RT when your market needs it (consoles, engines, developer adoption).
- Ship RT in a way that doesn’t destroy raster performance (because most pixels are still rasterized).
- Ship RT with an upscaling story (because brute-force RT is a performance tax).
From an SRE perspective, AMD optimized for reliability and predictable outcomes across a large installed base, not just for the top-end
benchmark chart. That’s not cowardice. That’s operations.
Joke #1: Ray tracing is like observability—once you turn it on, you immediately discover how much you didn’t want to know.
Facts and historical context that actually matter
Here are concrete points (not trivia) that shape why AMD’s “catch-up” strategy was rational:
- RT was “offline only” for decades: film/VFX pipelines used ray tracing long before real-time GPUs could, because they traded time for quality.
- DXR formalized a mainstream API: DirectX Raytracing made “RT as a pipeline” a standard, not a vendor demo.
- BVH acceleration structures are the real workhorse: fast RT depends on building and traversing BVHs efficiently; it’s not just “add RT cores.”
- Early real-time RT shipped hybrid: almost all shipping games use raster + limited RT effects (shadows, reflections, AO) rather than full path tracing.
- Consoles mattered: AMD-powered consoles brought RT hardware to a massive fixed platform, pushing engines to treat RT as a real feature, not optional.
- Upscaling became part of the RT deal: DLSS/FSR-style techniques turned “too slow” into “shippable” by trading resolution for temporal reconstruction.
- Driver/compiler maturity is a competitive advantage: RT workloads stress shader compilers and register allocation patterns differently than classic raster.
- RT performance is often memory/latency bound: traversal can be incoherent; caches miss; memory latency becomes the silent killer.
- Frame time consistency beats peak FPS: stutter from shader compilation or BVH rebuild spikes is what players feel, and what support tickets become.
What ray tracing really costs: a bottleneck taxonomy
1) Acceleration structure build/update cost (BVH)
RT doesn’t start with rays. It starts with data structures. The BVH (or similar) must be built or updated for geometry.
Dynamic scenes—animated characters, destructible objects, moving props—add build/update cost, and that cost can vary per frame.
In operational terms: BVH work is a variable batch job on your critical path. If you don’t bound it, it will page you at 2 AM
in the form of random stutter reports.
2) Traversal and shading incoherence
Rasterization has coherence: neighboring pixels often fetch similar textures, follow similar control flow, hit similar geometry.
RT can destroy that: rays bounce to unrelated parts of the scene. That means divergence in shader execution and terrible cache locality.
This is why “more compute” doesn’t linearly fix RT. Sometimes you’re waiting on memory. Sometimes you’re waiting on cache misses.
Sometimes you’re waiting on divergent execution because half the wavefront took a different branch.
3) Denoising and temporal accumulation
Real-time RT often uses few rays per pixel. Without denoising, you get sparkly nonsense.
Denoisers are compute workloads with their own bandwidth and cache behavior. They also introduce temporal stability issues:
ghosting, smearing, and the special pain of “looks fine while moving, breaks when you stop.”
4) Driver overhead and pipeline compilation
RT pipelines can increase shader variants and compilation complexity. If you hit runtime compilation—or worse, you ship without a warm shader cache—
your “RT is slow” bug is actually a “you compiled a shader mid-fight” incident.
5) The hidden tax: memory footprint
BVHs cost memory. Additional G-buffers cost memory. Higher-quality RT effects mean more intermediate buffers.
When VRAM pressure rises, you see eviction, paging, and sudden frame time spikes.
AMD’s RT approach: pragmatic engineering, not vibes
AMD’s RT entry with RDNA2 looked like a practical compromise: add hardware support (Ray Accelerators per CU) while keeping
the broader architecture balanced for raster performance and console constraints.
That’s the key: AMD didn’t build a GPU that is “an RT device that can also rasterize.”
They built GPUs that are still fundamentally raster-first, because that’s what most content still is.
The “catch-up” is intentionally constrained by reality: cost, power, yield, and broad compatibility.
If you run production systems, you recognize the pattern. You don’t rebuild the entire platform to support one new feature.
You make the feature work in the existing operational envelope. Then you iterate.
AMD also had a different strategic anchor: consoles. When your architecture is in consoles, you optimize for:
stable drivers, predictable memory behavior, and performance per watt in a fixed thermal box.
That tends to produce conservative, scalable choices rather than “throw transistors at the problem and pray.”
Here’s the uncomfortable truth: early RT adoption was partly a developer relations problem. If engines don’t ship RT paths broadly,
hardware RT is a shiny checkbox. Once consoles made RT more common, AMD’s timing looked less “late” and more “aligned.”
Measure first: what to collect before you “optimize”
The fastest way to waste weeks is to argue about RT performance based on average FPS screenshots.
You want frame time distributions, GPU/CPU splits, VRAM headroom, and shader compilation behavior.
A reliable workflow:
- Start with a reproducible scene: same camera path, same save point, same weather/time, same NPC state if possible.
- Capture frame times, not just FPS.
- Separate CPU-limited from GPU-limited cases.
- Test RT effects individually (reflections vs shadows vs GI) and record deltas.
- Track VRAM and system RAM pressure.
- Validate shader cache behavior after driver updates.
Quote (paraphrased idea): Werner Vogels popularized the idea that you should build systems expecting failure, and design for resilience rather than perfection.
— Werner Vogels (paraphrased idea)
Practical tasks: commands, output, meaning, decision
These tasks are written like you’re on-call and need answers, not vibes. They lean Linux-heavy because it’s scriptable and honest,
but the principles carry over. Each task includes: command, example output, what it means, and what decision you make.
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.
Joke #2: Turning on ultra RT settings to “test stability” is like load-testing your database by setting it on fire—technically informative, emotionally expensive.
Fast diagnosis playbook
This is the “you have 30 minutes before the meeting” workflow. It’s ordered to isolate the biggest buckets first.
First: prove what you are running
- Confirm GPU + driver stack (Task 1–2). If you can’t name it, you can’t fix it.
- Confirm API path: DXR/Vulkan RT extensions present (Task 3). No extensions, no RT path.
- Confirm settings are applied (Task 15). UI lies; config files rarely do.
Second: classify the bottleneck (CPU, GPU, memory, I/O)
- GPU vs CPU bound (Task 7). This determines whether you tune settings or threads.
- VRAM headroom (Task 6). If you’re near full, “RT is slow” might be “paging is slow.”
- System swap (Task 12). Swapping makes frame time tails ugly.
- Storage latency (Task 13). Shader/asset hitches can be I/O, not GPU.
Third: hunt spikes, not averages
- Frame time distribution (Task 8). p95/p99 are the truth.
- Shader/pipeline compilation evidence (Task 10, Task 9). Fix caching and precompile strategy.
- Thermals/power state (Task 4–5). If clocks drop, you’re losing the race before it starts.
Fourth: only then tune RT
- Disable one RT effect at a time (shadows, reflections, GI).
- Reduce bounce counts and ray distance.
- Prefer stable denoiser presets over aggressive ones that shimmer.
- Use upscaling intelligently; don’t treat native 4K RT as a moral achievement.
Three corporate mini-stories (the kind you learn from)
Mini-story 1: The incident caused by a wrong assumption
A mid-size studio shipped an RT patch for a cross-platform title. They tested on a few high-end GPUs, saw good averages,
and declared victory. Support tickets arrived like rain: “RT causes stutter every time I enter a new area.”
The wrong assumption was simple: they assumed “shader compilation happens during loading screens.”
In their engine integration, the RT pipeline variants for certain materials were only requested the first time a specific
combination of lights and surfaces appeared. That happened mid-game.
On some systems, the shader cache directory was on a slow, nearly-full SATA SSD. On others, it lived on a network-synced home folder.
The compilation itself was expensive; the cache writes made it worse. Players didn’t see a slow game. They saw an inconsistent one.
The fix wasn’t magical RT tuning. It was operational discipline: ship a warmed pipeline cache, compile ahead of time during
known transitions, and log cache misses with enough context to reproduce them. They also added an option to run a “shader warmup”
pass after driver updates.
Their biggest win was cultural: the team stopped using average FPS as their release gate and started using p99 frame time
thresholds per scene. The stutter complaints dropped sharply, even though average FPS barely changed.
Mini-story 2: The optimization that backfired
An internal graphics team tried to “optimize RT reflections” by increasing ray length and reducing sample count,
relying on the denoiser to fill in the gaps. On paper: fewer rays, faster frame.
In practice, the longer rays hit more geometry, caused more traversal steps, and produced noisier inputs to the denoiser.
The denoiser then needed more temporal accumulation to stabilize. That introduced ghosting during fast camera motion.
The team responded with more denoiser passes. GPU utilization went up, not down. Worse: memory bandwidth spiked, because the denoiser
moved lots of data through multiple buffers. On certain AMD cards, the workload became more sensitive to cache behavior and showed bigger p99 spikes.
They rolled back and took the boring approach: shorter rays, slightly more samples, and a denoiser preset designed for stability.
Performance didn’t “win” on a slide, but the game felt better and produced fewer corner-case artifacts.
The lesson: RT “optimizations” that increase variance are operational debt. If you can’t predict it, you can’t ship it safely.
Mini-story 3: The boring but correct practice that saved the day
A platform team maintained a lab of GPU test machines. Not glamorous. Mostly cables, labels, and a spreadsheet.
But they enforced a policy: every performance run logs driver version, kernel version, game build hash, config file, and a fixed camera path seed.
During a major update, someone reported “RT is 20% slower on AMD now.” The internet would have taken that and sprinted into a wall.
The lab didn’t. They reran the same test with the same camera path, then compared driver stacks.
The regression correlated with a driver update that changed shader compiler behavior. The game build didn’t change.
The team reproduced it on multiple machines, captured traces, and handed the vendor a tight repro package.
Meanwhile, they shipped a mitigation: a minor content change that reduced worst-case material divergence in the RT pass,
plus a default preset tweak that reclaimed frame time tail latency. Users saw improvement quickly.
The boring practice—structured test metadata and reproducibility—turned a potential blame storm into a solvable engineering ticket.
It didn’t make headlines. It saved the release.
Common mistakes: symptom → root cause → fix
This section is deliberately specific. These are the failure modes that waste real teams’ time.
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.
Checklists / step-by-step plan
Checklist A: If you’re buying/choosing hardware for RT workloads
- Define target: 60 fps locked, 120 fps competitive, or “cinematic 40 fps.” Don’t pretend these are the same requirement.
- Choose scenes that match your real workload: foliage, crowds, reflective interiors, nighttime neon—all stress RT differently.
- Measure p95/p99 frame time, not just averages.
- Budget VRAM headroom (at least a few GB) for RT buffers and future patches.
- Decide your upscaling policy upfront (FSR/DLSS/native). RT without upscaling is a luxury tax.
- Validate driver maturity for your OS and engine version.
Checklist B: If you’re a studio shipping RT on AMD (and everyone else)
- Build a reproducible benchmark path (fixed camera path, fixed seed, fixed settings file).
- Ship a shader/pipeline warmup path and log cache misses.
- Expose RT features as independent toggles (shadows/reflections/GI) and keep presets sane.
- Cap acceleration structure build/update cost per frame; defer non-critical updates.
- Prefer stable denoising over aggressive low-sample hacks that shimmer.
- Test VRAM pressure explicitly: “near full” is a separate test mode.
- Maintain a driver matrix and rerun baselines after driver changes.
- Make “p99 frame time” a release gate for RT presets.
Checklist C: If you’re troubleshooting “RT is slow” as an operator
- Confirm hardware and driver stack (Tasks 1–2).
- Confirm RT API availability (Task 3).
- Classify the bottleneck (Task 7, 6, 12, 13).
- Measure frame time tails (Task 8, 16).
- Look for compilation (Task 10) and cache issues (Task 9).
- Check thermals and clocks (Tasks 4–5).
- Only then tune RT settings; don’t tune blind.
FAQ
1) Is AMD “bad at ray tracing”?
No. AMD’s RT performance depends heavily on the game, engine integration, and settings. The more a workload is memory-latency bound and divergent,
the more architectural differences show up. Treat it as a workload match problem, not a morality play.
2) Why does RT feel worse than raster even when FPS looks okay?
Because RT often worsens tail latency. p99 frame times matter more to perceived smoothness than average FPS.
Spikes come from compilation, BVH rebuilds, and memory pressure.
3) Why do reflections cost so much more than shadows sometimes?
Reflections often require longer rays, more complex shading, and more incoherent hits. Shadows can be cheaper if they’re
limited-range and single-bounce.
4) Should I always enable upscaling with RT?
In most real-time titles, yes. Upscaling is part of the RT performance budget. Run at a lower internal resolution and spend
the saved time on RT effects and stable denoising.
5) What’s the biggest “gotcha” in RT performance testing?
Shader cache and pipeline compilation. If your first run includes compilation and your second run doesn’t, you didn’t benchmark RT;
you benchmarked your build pipeline.
6) Why can a driver update change RT performance so much?
RT shader pipelines stress compilers differently: register allocation, scheduling, and occupancy can change.
Also, driver updates can invalidate caches, causing first-run stutter.
7) What should studios prioritize: peak FPS or frame time consistency?
Consistency. A stable 60 fps with good p99 feels better than a 90 fps average with regular 40 ms spikes.
Stability also reduces support load and negative reviews.
8) Does “more RT hardware” automatically mean better RT?
Not automatically. Traversal and shading can be limited by memory latency, cache behavior, divergence, and denoiser cost.
Hardware helps, but the workload and software stack decide the outcome.
9) If I’m GPU-bound with RT on, what setting usually gives the best win?
Reduce RT resolution (often via upscaling mode), then reduce ray distance and bounce count.
Disabling the single most expensive RT effect (often reflections/GI) can reclaim massive frame time.
Practical next steps
If you take one thing from AMD’s RT story, take this: sequencing matters. Shipping RT later with a robust stack is not failure;
it’s a disciplined trade between feature ambition and operational correctness.
Do this next, in order:
- Stop arguing about average FPS. Collect p95/p99 frame times and make decisions from tails.
- Build a reproducible RT benchmark path and log the full stack: driver, kernel, build hash, settings.
- Guard VRAM headroom. If you’re within a couple GB of the limit, your next patch will become a stutter generator.
- Fix shader/pipeline compilation behavior. Warm caches, precompile, and keep the main thread clean.
- Tune RT like an operator: isolate one variable at a time, measure deltas, and prefer stability over fragile wins.
“Catching up” is what you call it when you only watch the race. When you run the system, you call it risk management.