Proposal: place GPU-oriented guest memory in VRAM via SAM / Resizable BAR (Linux, RX 9070 XT) #2

Status (2026-10-09)

• Research: source-level results are in this comment.
• RADV support: memoryMapPlaced and memoryUnmapReserve are supported, alignment is the page size, and placed VRAM pays no per-submit cost.
• memoryMapRangePlaced is false: each guest mapping needs its own allocation, which answers that open question.
• Risk: CPU-visible VRAM is a write-combined I/O mapping. vram_bench access tests atomics, read(), O_DIRECT, futexes and process_vm_readv on it.
• Tools: for Steps 0–2 on branch groundwork.
• Next: remaining work and the order to do it in: NATIVE_RDNA_NEXT.md.

Proposal

Place the guest memory a PS5 title uses for GPU data in VRAM, mapped into the CPU through SAM (Resizable BAR) at the guest address the title expects. CPU-oriented memory stays in system RAM. The GPU then reads that data at VRAM bandwidth instead of over PCIe, with no imports, no pinning and no copies for it.

• Hardware: Radeon RX 9070 XT (16 GB) with SAM enabled, on Linux with RADV.
• Independence: this is separate from Proposal: native RDNA4 path on Linux — PS5 shaders translated gfx1013 → gfx12, direct amdgpu submission (PoC: Dreaming Sarah) #1, the native RDNA4 path, and neither depends on the other.
• First target: upstream's existing SPIR-V/Vulkan path, which runs every title upstream runs today.
• Later: the same placement serves Proposal: native RDNA4 path on Linux — PS5 shaders translated gfx1013 → gfx12, direct amdgpu submission (PoC: Dreaming Sarah) #1's direct amdgpu backend.

Why: what guest memory costs today

A PS5 title assumes its CPU and GPU share one memory. On a PC with a discrete GPU they don't, and upstream's driver spends a lot of effort on that gap:

How upstream handles guest memory on Linux today:

• Direct memory is backed by memfd (core/libs/prx/libkernel/DirectMemory/DirectMemory.cpp). The driver imports the ranges the GPU uses as udmabuf dma-bufs (feat(agc): import shared direct memory through udmabuf on Linux boykopovar/AnyPS5#943), or as host pointers.
• CPU writes are tracked (core/libs/prx/libSceAgcDriver/Execution/src/GuestMemory.cpp) so the driver knows what to copy or re-upload.
• Read-only buffers are snapshotted and copied (perf(agc): reuse unchanged draw input snapshots across draws boykopovar/AnyPS5#276), and GPU results are written back (Graphics/src/GuestBufferMemory.cpp).
• No allocation uses host-visible VRAM. Every allocation is either GPU-only VRAM or host-visible system memory (Graphics/src/GuestBufferMemory.cpp:1823, Graphics/src/BufferPool.cpp:58).

What SAM can and can't do

SAM lets the CPU map all of VRAM instead of a 256 MB window. The CPU still reaches it over PCIe, so:

• CPU reads from VRAM are very slow. The mapping is uncached or write-combined, so each load is a PCIe round trip of about a microsecond, against about a nanosecond for a cache hit. Vulkan exposes this memory as DEVICE_LOCAL | HOST_VISIBLE but not HOST_CACHED on discrete GPUs. Data the CPU reads must stay in system RAM.
• CPU writes into VRAM are fine. Write-combining merges them into full bursts.
• The GPU reads VRAM at full bandwidth, instead of reading system memory over PCIe.

So SAM gives a CPU window into GPU memory, not shared memory. The design depends on putting only the right memory there.

Design: placement by the title's own hints

Signals the title already gives:

• The memory type passed when it maps direct memory, or changes with sceKernelMtypeprotect. Upstream records it for each mapping (DirectMemory.cpp: memoryType, DoMtypeprotect, QueryDirectMapping).
• GPU access on the mapping. Upstream's allocation registry already knows which ranges were mapped with GPU access (fix(agc): import GPU-mapped guest memory when it is mapped boykopovar/AnyPS5#1961).

Policy:

• Mappings with GPU access and a GPU-oriented, write-combined memory type go into VRAM.
• Everything else stays in system RAM on the current path.
• PS5 titles already avoid CPU reads of GPU-oriented memory, because those reads are slow on the console too.

Mechanism on the SPIR-V/Vulkan path:

• Allocate VkDeviceMemory from a DEVICE_LOCAL | HOST_VISIBLE memory type.
• Map it at the guest address with VK_EXT_map_memory_placed: vkMapMemory2KHR with VkMemoryMapPlacedInfoEXT. This works like mmap with MAP_FIXED. RADV has supported it since early 2024, and Wine uses it for WOW64.
• The memory is the driver's own allocation, not an import. It needs no userptr or udmabuf and no pinning. Per perf(agc): share one dma-buf import per 64 MiB of Linux direct memory boykopovar/AnyPS5#1152's measurements, ordinary allocations don't carry the per-submit validation cost imports do.
• Buffers inside these ranges are bound directly. No snapshot copies, no write-back.
• Textures that the driver detiles into separate images still need upstream's dirty tracking, at least until Proposal: native RDNA4 path on Linux — PS5 shaders translated gfx1013 → gfx12, direct amdgpu submission (PoC: Dreaming Sarah) #1's surface design applies.

Mechanism on the native path (#1):

• A VRAM buffer object allocated through libdrm_amdgpu.
• Mapped into the CPU at the guest address (DRM render node mmap with MAP_FIXED), and into the GPU at the same virtual address.

Fallback and budget:

• Anything that cannot be placed stays on the current path.
• VRAM is 16 GB, and titles can reserve most of their 13.5 GiB of direct memory (BC5 reports 12.4 GiB of GPU-visible memory for Astro Bot). Render targets, detiled copies and the desktop also need VRAM.
• So placement runs under a budget. When VRAM is full, new GPU-oriented mappings fall back to system RAM, and the choice is logged.

Steps

Step 0: Check the hardware and driver

• lspci -vv shows the GPU's BAR at full VRAM size.
• vulkaninfo lists a DEVICE_LOCAL | HOST_VISIBLE heap of about 16 GB.
• VkPhysicalDeviceMapMemoryPlacedFeaturesEXT reports memoryMapPlaced (and memoryMapRangePlaced). Record minPlacedMemoryMapAlignment.

Step 1: Memory census

• Log every direct-memory mapping for Dreaming Sarah, and for a heavier title that runs on upstream Linux: memory type, size, GPU access, later type changes.
• Measure how often the CPU reads each GPU-oriented range, using a debug-only run:
  • Map the range PROT_NONE and count faults.
  • On x86-64 Linux, bit 1 of the page-fault error code (REG_ERR in the signal's ucontext) separates writes from reads.
• Output: which memory types hold what, how much would go to VRAM, and whether any GPU-oriented range is read often enough to hurt in VRAM.

Step 2: Microbenchmark, standalone

Allocate DEVICE_LOCAL | HOST_VISIBLE memory and map it at a fixed address with VK_EXT_map_memory_placed. Measure:

• CPU streaming-write bandwidth (memcpy into it);
• CPU read latency and bandwidth;
• GPU read bandwidth from it, against a udmabuf import of system memory;
• vkQueueSubmit cost with N such allocations, against N imports (repeating perf(agc): share one dma-buf import per 64 MiB of Linux direct memory boykopovar/AnyPS5#1152's table).

Step 3: Integration

• libkernel: a VRAM backing kind for direct memory, chosen by the policy above. It is created through a hook the AGC driver provides, because it needs the Vulkan device.
• Guest arena: placed maps go into the arena's reserved range at the guest address, honouring minPlacedMemoryMapAlignment.
• Driver: binds these ranges directly, skips imports, snapshots and write-back for them, and keeps dirty tracking where derived copies (detiled textures) need it.
• Debug switches: one to turn placement off, and one to log every decision.

Step 4: Measurement

• Run Dreaming Sarah and the heavier title with placement off and on.
• Compare: [guestmem] copy and compare bytes, import counts, vkQueueSubmit time ([recorder] lines under APS5_PROFILE_DRAW=1), frame time and 1% lows (APS5_ENABLE_TIMING_LOG=ON).
• Check correctness with frame dumps (APS5_DUMP_FRAMES).

Milestones

• M0: ReBAR and VK_EXT_map_memory_placed confirmed on the RX 9070 XT (Step 0)
• M1: memory census for two titles (Step 1)
• M2: microbenchmark results (Step 2)
• M3: placement integrated behind a switch (Step 3)
• M4: before/after measurements (Step 4)

Success criteria

• Copy, compare and write-back traffic for GPU-oriented ranges drops to near zero.
• Per-submit cost no longer grows with the number of GPU-used allocations.
• Frame time improves, or at least does not regress, on both titles.
• Frames match placement-off runs.
• Unsupported states throw, as upstream requires. No silent fallbacks beyond the logged budget fallback.

Open questions

• How does a placed map interact with upstream's guest arena reservation (GuestArena in libc)? Can the arena's reserved pages be replaced in place, as MAP_FIXED does?
• Does upstream's Linux write tracking (GuestWriteWatch, page queries) work on a placed device-memory mapping?
• How do titles actually use memory types? Is any GPU-oriented memory read by the CPU often enough to hurt in VRAM? Step 1 answers this.
• What happens under VRAM pressure? The kernel can evict buffer objects to system memory. Is that transparent through the CPU mapping, and how slow is it?
• Is memoryMapRangePlaced needed, for a guest mapping that covers part of an allocation?
• Can a title change a placed range's memory type to a CPU-oriented one, and does that need migrating the range back to system RAM?
• Native path (Proposal: native RDNA4 path on Linux — PS5 shaders translated gfx1013 → gfx12, direct amdgpu submission (PoC: Dreaming Sarah) #1): can a VRAM buffer object be mapped at a fixed CPU address through the DRM render node (mmap with MAP_FIXED) while staying "always valid" in the GPU VM?

Out of scope

• Windows: we don't know whether AMD's Windows driver supports placed maps, and there's no hardware here to test it.
• The native shader path. That is Proposal: native RDNA4 path on Linux — PS5 shaders translated gfx1013 → gfx12, direct amdgpu submission (PoC: Dreaming Sarah) #1.
• Changes to the relinker.

References

• VK_EXT_map_memory_placed: proposal, reference page, Wine's use of it
• Upstream PRs on guest memory: #5, #276, #943, #1152, #1961, #1970
• BC5 (same-address dma-buf mapping on the BC-250): https://github.com/RedMadKnight/BC5
• Upstream: https://github.com/boykopovar/AnyPS5