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

PSP GE and Graphics Pipeline for Recompiler Authors

Posted
Updated
ByJstar269

Type: REFERENCE   Status: MAINTAINED   Scope: GE display lists, state, surfaces, and renderer boundaries

The Graphics Engine is a command processor and rendering pipeline, not a single drawing function. A static recompiler translates the guest CPU code that builds and submits display lists; the runtime must interpret or translate the dynamic command stream, guest memory references, render state, and synchronization.

How We Know

guest CPU
   |
   '-- build 32-bit GE commands in guest memory
           |
           v
      enqueue / stall / signal / finish
           |
           v
 software GE or host GPU backend
           |
           +--> vertex/index/texture/CLUT reads
           +--> transform/lighting/raster state
           '--> framebuffer/depth target + synchronization
Source-owned GE pipeline diagram.

Display lists and scheduling

PRIOR ART: a GE command is a 32-bit word with an opcode/address field and data field. Public documentation lists commands for vertex/index addresses, primitives, frame/depth buffers, textures, matrices, lighting, blending, and control flow. PSPSDK exposes enqueue-head/tail, stall updates, list sync, break/continue, callbacks, and context save/restore.

A display list can stall, branch/call, signal, finish, and resume. Therefore a host renderer that simply walks until an END command is not a complete GE scheduler model.

Inputs and state

  • Vertex/index input is guest memory with PSP formats, alignment, and optional indexing.
  • Transforms and matrix stacks affect screen coordinates, clipping, and depth.
  • Lighting, texturing, CLUT, swizzle, blending, depth/stencil, dithering, and color formats are persistent state, not per-draw local variables.
  • Framebuffer/depth base and stride fields define guest surface addressing.

Software renderer versus host GPU

IMPLEMENTATION FACT: Nakagawa has a software GE path and an optional SDL3/Vulkan backend. The backend maintains GPU images and explicitly handles guest framebuffer ownership/readback. This is a compatibility-runtime boundary, not a claim that the host GPU is architecturally identical to the PSP GE.

Use software/host-GPU parity to localize a divergence. Use a PSP-visible oracle or source-owned numeric probe to claim hardware behavior. Do not use screenshots or commercial title assets as a substitute for public-safe conformance fixtures.

What a recompiler must preserve

  • Guest pointer and stride interpretation for vertices, indices, textures, CLUTs, and surfaces.
  • List ordering, stalls, callbacks, signal/finish events, and sync return states.
  • State persistence across list calls and context save/restore.
  • CPU writes versus GPU reads and GPU writes versus CPU readback ownership.

Do Not Infer

  • Full software-renderer coverage is not full PSP GE coverage.
  • One supported primitive or pixel format does not establish every GE command.
  • Host GPU output parity is not an external PSP visual oracle.
  • Display latching and GE/VRAM coherency are separate problems.

Open questions

High-value public work includes synthetic list scheduling fixtures, SIGNAL/FINISH callback matrices, stall/break/continue behavior, state persistence, format/CLUT/swizzle coverage, depth/blend corner cases, and CPU/GPU ownership properties. See Open Research Questions and VRAM/Framebuffer Coherency.

Primary sources

Table of Contents