The WebGPU Runtime: Recreating PS2 Hardware in the Browser

A PS2 Web Recomp port is two artifacts in one page: the translated game, which is WebAssembly, and the runtime underneath it, which recreates the PlayStation 2 hardware the game expects to find. The runtime is the half that decides how faithful and how fast a port feels — and its choice of WebGPU as the rendering foundation is the single most consequential technical decision in the scene. This page explains what the runtime recreates, why WebGPU is the right tool, and where its young edges show.

What Gets Recreated

The PlayStation 2 is an unusual machine, and the runtime has to stand in for all of its unusual parts. The Emotion Engine is the heart: a MIPS R5900 core at its center, flanked by two Vector Processing Units — the VU0 and VU1 — that games used as miniature supercomputers for geometry and effects, plus a DMA controller that moves data between chips in the background. The translated game code executes as WebAssembly, but every co-processor interaction, every DMA kick, every scratchpad access lands on the runtime to satisfy.

The Graphics Synthesizer is the stranger half. The PS2 GPU was not a modern programmable chip; it was a fixed-function beast with 4MB of embedded video RAM, unusual drawing modes, and a direct relationship with the VRAM that games manipulated in ways no modern API contemplates. A runtime must translate all of that — the drawing commands, the texture formats, the frame buffer tricks — into operations a current GPU performs through WebGPU.

Around them sit the supporting cast: the SPU2 sound processor whose mixing the runtime reproduces for the game's audio streams, the timer and interrupt controllers whose pacing games subtly depend on, and the memory map that ties it together. Fidelity here is invisible when right and unmistakable when wrong — a missing DMA behavior or a mis-timed interrupt surfaces as exactly the kind of glitch emulation veterans recognize.

Why WebGPU and Not WebGL

The browser offers two serious graphics APIs, and the choice between them shapes everything. WebGL wraps the old OpenGL model: single-threaded command submission, no compute shaders in the common profiles, and a design that predates modern GPU architectures. It kept web graphics alive for fifteen years, but its ceiling is real.

WebGPU is the modern answer: a clean API explicitly designed to sit atop Vulkan, Metal and DirectX 12, exposing the GPU the way current hardware actually works. For the PS2 Web Recomp runtime the differences that matter are concrete. Multi-threaded command preparation maps onto the PS2's parallel chip design instead of fighting a single-threaded pipe. Compute shaders let the runtime implement the Vector Processing Units and pixel-level Graphics Synthesizer behaviors on the GPU itself rather than shuffling work to the CPU. The memory-control features — buffers, bind groups, explicit synchronization — match the DMA-and-transfer character of the console far more honestly than WebGL's object model ever could.

The result is the scene's headline quality: ports like God of War II rendering at full speed on ordinary machines. A WebGL runtime could approximate the same hardware; it could not approximate the same performance.

The Young Edges

The runtime is weeks old at this writing, and honesty about its edges is part of tracking the scene. Heavy special effects — the full-screen passes, particle storms and blending modes that late-generation PS2 titles used to dazzle — land on the least-mature parts of the Graphics Synthesizer recreation, and the launch-week community discussions were candid about the performance cliffs some of them hit. Timing-sensitive games stress the interrupt and timer emulation in ways lighter titles never do. And WebGPU itself varies slightly across browsers and driver versions, so a port can behave differently at the margins on Chrome versus Firefox versus Edge.

The direction of travel matters more than the current state. Every runtime release widens the implemented surface and tightens the hot paths; every new game that lands playable is evidence the gaps are closing. This is the standard arc of a young runtime, compressed by how much the underlying techniques were already proven in the native recomp world.

The Runtime as the Scene's Shared Engine

The final thing to understand about the runtime is structural: it is shared infrastructure, not per-port code. Every game that gets recompiled runs against the same WebAssembly-and-WebGPU hardware recreation, which means every port that ships is simultaneously a test suite for the runtime. A quirk discovered porting one title gets fixed once and every past and future port inherits the fix. That flywheel — more games, better runtime, easier next game — is the strongest argument that the playable list's growth accelerates from here.

The Audio Half: SPU2

The sound processor deserves its own moment, because audio is where a young runtime betrays itself first and where players notice betrayal most. The PS2's SPU2 is a pair of sound processing units with their own voice-based synthesis model — games uploaded small sample programs and let the hardware mix, pitch and place them. The runtime reproduces that model in the browser's audio stack, and the discipline shows: when the SPU2 recreation is right, God of War II's orchestral score lands with full weight; when a path is missing, it lands as silence or worse. The scene's launch-week audio quality was one of its quieter victories — voices, music and effects held up through the demonstrations, which is unusually good for a runtime this young.

Audio also explains a class of reports worth understanding: audio crackle under heavy scenes is usually not an audio bug but a frame-pacing bug — the whole simulation slowing enough that the audio stream underruns. Fixes that improve rendering throughput make the crackle vanish, which is why the scene treats audio glitches as performance telemetry as much as sound problems.

Cross-Browser Reality

Because WebGPU sits on each browser's implementation of Vulkan, Metal or DirectX 12, ports inherit per-browser edges. Chrome is the development reference and generally the smoothest experience. Edge matches it, sharing the engine. Firefox's WebGPU implementation is younger and occasionally differs at the margins — a feature path landing a release later, a performance profile a step apart. None of this fragments compatibility the way old plugin wars did; the API contract holds everywhere. But benchmark-bragging between browsers is part of the scene's culture now, and the practical advice is simple: use a current browser, and if you have two installed, try the port in both before concluding anything about the port itself.

Why Players Should Care About Any of This

The machinery matters because it decides the experience. A runtime on WebGL would have meant compromises — stutter in heavy scenes, effects approximated, the flagship port impossible at its current quality. The WebGPU choice is why the scene's first month produced a full-speed God of War II rather than a tech demo of a menu screen. Every complaint the runtime cannot yet answer traces to unfinished recreation work; every strength it shows traces to the architecture being right from the start. Players do not need to understand compute shaders to benefit from them — they just need to know that the check on chrome://gpu is the gate, and the gate opens onto machinery built for exactly this.

For the game-by-game state of that flywheel, the playable games list is the scoreboard. For the technique that produces the translated half of every port, the static recompilation page is the deep dive. This page stays focused on the hardware half — the quiet, decisive work of making a browser behave, just enough and just in time, like a PlayStation 2.