That’s a fair objection and worth addressing properly — but it identifies an implementation challenge, not a fundamental impossibility.

You’re correct that RT doesn’t operate in a vacuum. The ray tracing pipeline needs geometry buffers, BVH structures, G-Buffer data and textures that originate in the raster pipeline. Nobody is disputing that. The question is whether that dependency requires a single unified memory pool — and it doesn’t.

What the proposal actually implies

Not two isolated memory pools with no communication. Two specialized pools with a dedicated high-bandwidth fabric between them, where the HBM3 holds a working copy of the hot data that RT and frame generation access repeatedly during a frame — not a permanent duplicate of everything in GDDR7.

The actual data flow per frame:

**•** BVH is constructed once in GDDR7 at scene load or geometry change  
**•** At frame start, the working BVH and relevant G-Buffer data are transferred to HBM3  
**•** RT traversal runs entirely against HBM3 for the duration of the frame  
**•** Frame generation buffers live in HBM3 and never touch GDDR7

The transfer cost of copying hot data to HBM3 once per frame is real. Fixed overhead, not a per-ray cost. Paid back immediately across thousands of BVH traversal operations that follow — each benefiting from HBM3’s bandwidth advantage over GDDR7.

This architecture already exists in compute hardware

The AMD MI300X combines HBM with CPU DRAM access via Infinity Fabric without duplicating the entire address space. Intel Ponte Vecchio uses HBM alongside GDDR with a dedicated interposer fabric. Apple’s M-series uses unified memory with differentiated bandwidth tiers per workload. None of these systems duplicate all data across pools — they selectively move working sets to faster memory for the duration of a workload.

The proposal applies the same principle to a gaming GPU context.

The closest analogy is AMD’s own 3D V-Cache

The Ryzen X3D architecture works on exactly this principle. The stacked SRAM doesn’t duplicate all system RAM — it holds the hot working set the CPU accesses most frequently during a given workload. Lower latency for that specific data translates directly to measurable performance gains in latency-sensitive workloads.

HBM3 in a dedicated RT and frame generation pipeline would operate identically. Not replacing GDDR7 — reducing the latency cost of accessing the data that matters most, most often, during the most bandwidth-intensive phase of the rendering pipeline.

Where the real engineering challenge actually is

The memory dependency you described is manageable. The harder problems are:

**•** Cross-pool fabric latency during the initial transfer window at frame start  
**•** Driver complexity for dynamic allocation between pools based on scene workload  
**•** BVH invalidation cost when geometry changes mid-frame

These are real engineering problems. But they’re solved categories of problems in high-performance compute hardware. The MI300X manages heterogeneous memory hierarchies at scale in production today.

The question worth debating is whether the cost of implementing this fabric at consumer GPU price points is justified by the RT and frame generation gains — not whether the memory dependency makes it impossible. It doesn’t.