Skip to main content
How Can We Help?
< All Topics
Print

PSP Display, VBLANK, and Framebuffer Latching

Posted
Updated
ByJstar269

Type: REFERENCE   Status: MAINTAINED   Scope: display descriptors, VBLANK synchronization, and presentation ownership

Display presentation sits below the existing VRAM/Framebuffer Coherency article. The important separation is: a framebuffer descriptor tells display hardware what to scan out; GE rendering writes guest-visible surfaces; VBLANK provides a synchronization boundary; CPU/GPU ownership determines when bytes are visible. These are related contracts, not one “swap buffers” operation.

How We Know

CPU writes / GE renders
          |
          v
guest framebuffer bytes + descriptor (base, stride, format)
          |
          +--> GPU/GE ownership transition
          |
          '--> VBLANK/latch boundary --> display scanout
Source-owned display ownership diagram.

Framebuffer descriptor

A display buffer is more than a pointer. Base address, stride, pixel format, and sync/latch mode determine how the panel interprets guest memory. The PSP display API exposes current/next-framebuffer operations and VBLANK waits; exact return/error behavior belongs to the named API and firmware scope.

Stride is especially important: a 480-pixel visible width can live in a wider guest row. Any host presentation path that assumes tightly packed rows can produce a plausible but wrong image.

VBLANK is a synchronization source

PRIOR ART: PSPSDK distinguishes wait-for-VBLANK, wait-for-VBLANK-start, and callback-aware variants. A runtime can model VBLANK as a delivered interrupt/event quantum, but it must preserve the API’s wait, counter, and callback relationship.

IMPLEMENTATION FACT: Nakagawa’s scheduler coalesces a pending VBLANK source while interrupts are disabled and delivers it at the scheduler boundary. This is a runtime design point, not proof of every display interrupt edge.

Latch versus coherency

“Next sync” or “latch” semantics decide when a display descriptor becomes active. They do not flush a host GPU image, invalidate CPU caches, or guarantee that a just-rendered target has been copied back to guest memory. Keep presentation ownership and memory/GPU coherence as separate state transitions.

Do Not Infer

  • Calling a buffer-swap helper does not prove PSP display latch timing.
  • Software-renderer/host-GPU parity does not prove PSP scanout behavior.
  • One framebuffer address does not establish stride, format, or current/next semantics.
  • One VBLANK route is not complete display-driver coverage.

Open questions

Source-owned numeric probes should cover current versus next sync, multiple queued calls, VBLANK counter edges, format/stride combinations, and display changes concurrent with GE rendering. Keep video captures and private title assets out of the public article.

Primary sources

Table of Contents