VRAM and Framebuffer Coherency: Explicit Ownership Across CPU and GPU Paths
Status: IMPLEMENTATION FACT / DERIVED · Evidence: current public renderer architecture and explicit state-transition model · Last reviewed: 2026-08-11
Why a single “VRAM buffer” is not enough
A PSP framebuffer can be written by the guest CPU, consumed by the graphics engine, read back for screenshots or texture uploads, and presented by a host renderer. A correct implementation must track ownership and visibility between those paths. Treating a host texture cache as an always-current copy of guest memory creates stale-frame and readback bugs that can look like shader or rasterization errors.
Useful state transitions
| Transition | Required action | Evidence label |
|---|---|---|
| guest CPU write → GPU read | mark the affected guest span dirty and upload/invalidate before sampling | IMPLEMENTATION FACT |
| GPU render target write → guest read | resolve or read back the target before exposing bytes to guest code | DERIVED contract |
| GPU write → present | finish the render-target transition before presenting the image | IMPLEMENTATION FACT |
| capture/debug read | identify whether the source is guest memory or the resolved host image | evidence qualification |
Public implementation anchors
The software GE path in src/rt/ge.c and the Vulkan/SDL path under src/rt/gpu_sdl3vk are public review targets. Their existence is an implementation fact; parity between software and Vulkan is a useful localization signal, not an external PSP oracle.
How to test coherency
Use a synthetic pattern that changes in guest memory after a texture has been uploaded, then assert that a GPU read sees the new bytes only after the documented dirty transition. Run the reverse case by rendering a pattern and reading it back through the guest-visible path. Add a present/capture case so a screenshot cannot silently read an older staging image. Record the source surface, transition, and expected visibility in each assertion.
No proprietary screenshot, retail asset, or private trace is required. Report software-vs-Vulkan parity as differential evidence and reserve hardware claims for a qualified Hardware Oracle Methodology route. Apply the Evidence Standard when a capture is unavailable or only local.
Related reading: Static Recompilation Architecture, Nakagawa Recomp Case Study, and Open Research Questions.