DOOM homebrew (PPSA99666 v1.1.1) on Windows / RTX 3060: startup reproduction and AGC CPU fallback

[RipcuBAN]

I reproduced startup of lowbit's public PS5 DOOM homebrew with AnyPS5 on Windows. The guest executable reached its entry point, created a Vulkan window on an RTX 3060, and subsequently logged DOOM shareware initialization. The first AGC presentation frame failed and the port switched to its CPU scaler.

Scope: startup and log observations only. I have not visually verified rendering, tested movement/firing, heard the audio, or established sustained gameplay stability. The window-title FPS counter is not a gameplay benchmark. This is the homebrew port of classic DOOM, not a retail PS5 DOOM title.

Existing work

This is an additional reproduction, not a first-run claim. I searched Discussions for DOOM and found no matching discussion, but the issue history already contains relevant results:

• Four open-source homebrew titles stop at start-up on unresolved imports (sysctl, pthread_set_name_np, isatty, mkstemp, signal sets, Opus decoders) #1578: LeandroLP23 reports ps5-doom running on Windows as an import-audit control.
• Linux: a bundled libc.prx loader shim (ps5-native-app-boilerplate) binds libc imports to placeholder exports; DOOM PPSA99666 finds no WAD #1497: hikazey reports Linux gameplay and the same first-frame/CPU-scaler fallback; that thread also covers bundled libc shim binding and references docs: record DOOM homebrew integration compatibility #690 and fix(relinker): keep Linux imports declared from host modules off guest exports #1529.
• PS4 vs PS5 executables: the SELF container is the same format (measured) #2433 is related PS4/PS5 container research. Container extraction alone does not establish PS4 runtime compatibility.

Sample and build

• Public release: lowbit/ps5-doom v1.1.1, title PPSA99666.
• Corresponding source: commit ba6e305bd315828c0980ff93eb54e35c8ebf397b.
• Release ZIP SHA-256: 4d8e5b785b61696fbf1988c2d0d87c5c977734ff60b1ce11cc49134b0e711b5f.
• Reconstructed eboot ELF SHA-256: 62d4cfe60815afbbebbd1916eb6b08fa5bd53e36d3ced68d9b62a6488bb37378; it matches the digest recorded in the plaintext FSELF container.
• Windows, Ryzen 5 7600X, NVIDIA RTX 3060, MinGW-w64 GCC 15.2.0.
• AnyPS5 upstream base: 025a911. This used a modified local branch, not current stock main. It includes a kernel AIO polling overlap fix and Random tests/build changes. Local final commit: 55be23de014730a11b756ef140c29f0802a1179d (not published).

The local VideoOut build needed two redundant APS5_EXPORT alias lines removed to avoid duplicate identifiers during NID patching:

• Event.cpp: alias LibwuIonIBw for sceVideoOutAddVrrActiveStatusEvent.
• Output.cpp: alias kP2L8t3j-aM for sceVideoOutAddVrrStatusFlagsPrivilege.

The named exports already produce those NIDs; both expected exports were still present after patching. This is a local build observation, not a claim that current main still needs this change.

Conversion and runtime layout

The plaintext executable and companion sce_module/libc.prx were reconstructed from the public release. The original guest machine code was relinked; it was not regenerated from AI-written or decompiled C.

The relinker command was:

relinker.exe --windows --windows-diagnostics --registry source/eboot.elf runtime/doom.exe

Runtime files were arranged as doom.exe, libs/*.prx, app0/sce_module/libc.prx.guest.prx, app0/wads/doom1.wad, and app0/sce_sys metadata. A download0 directory was added after the initial missing-directory warnings. The libraries, relinker and converted guest module were built/prepared locally.

Import audit across the executable and companion registry found 274 references / 262 unique imports: 257 classified implemented, 5 classified stubs, 0 absent imports and no missing libraries. Those classifications are static heuristics; they do not certify each function's behavior or mean every listed stub is reached.

Log evidence

Transferring control to ELF entry point
Selected GPU name=NVIDIA GeForce RTX 3060
[debug:0] video: AGC compute presentation
[Shaders/ShaderRegistry.cpp:221 InvocationFor] Compute shader 0x202a81800 was not registered; preparing its artifact at dispatch
[debug:0] gpu: frame 1 never completed
[debug:0] video: GPU presentation failed, switching to the CPU scaler
[debug:0] launcher: starting DOOM SHAREWARE: EPISODE 1 from /app0/wads/doom1.wad
[debug:0] audio: output open at 48000 Hz
[debug:0] startskill 2  deathmatch: 0  startmap: 1  startepisode: 1
[debug:0] ST_Init: Init status bar.

The process remained alive after a 15-second observation and was reported responding. Recorded window titles included DOOM | FPS: 59.94 (469) and later DOOM | FPS: 34.99 (1466). Audio initialization in the log is not an audible-output check.

Static analysis workflow

A separate SHA-keyed Ghidra 12.1.4 cache recovered four selected functions (_start/main/plat_exit/D_DoomMain, names inferred from the pinned sources). A pre-analysis script registered the declared e_entry for ELF type 0xfe10 without modifying input bytes. Local timings were 33.48 s for initial analysis, 6.55 s for a subsequent four-function query, and 1.98 ms for an identical cached query. The pseudocode still has unresolved PS5 import/relocation typing issues and is not a buildable replacement or a proof of semantic equivalence.

Does anyone have a successful AGC presentation trace for this exact release on NVIDIA, or a preferred existing thread for consolidating these DOOM observations? The useful next check here is the first-frame failure and a visual/gameplay verification, rather than adding a playable compatibility claim prematurely.

Prepared and investigated with AI assistance (Codex); observations above distinguish actual execution from static inference.

[ycbuzi]

Answers to your three open questions, from the same release on a different NVIDIA card.

Windows 11 (26200), Ryzen 9 7900, RTX 4070 SUPER, WinLibs GCC 15.2.0 r7, Release. Same sample: lowbit/ps5-doom v1.1.1, PPSA99666.

1. "Does the VideoOut alias removal still apply to current main?" — No, it is fixed upstream.

You were right to hedge that one. Both alias lines are gone from main: a3ca03e0 fix(videoout): remove duplicate VRR exports, merged as #2473. I build main + a local stack with no VideoOut workaround and libSceVideoOut.prx links cleanly, so that item can come off your list.

2. "Does anyone have a successful AGC presentation trace on NVIDIA?" — Not here either.

The fallback reproduces on the 4070 SUPER, on the same kernel address you logged:

video: AGC compute presentation
Compute shader 0x202a81800 was not registered; preparing its artifact at dispatch
gpu: frame 1 never completed
video: GPU presentation failed, switching to the CPU scaler

That makes at least three NVIDIA generations behaving identically — your 3060, @babyhuey's 3080 on #690, and Ada here. One caveat worth flagging rather than burying: was not registered appeared exactly once per run on all three of my runs, including two where the disk cache reported 1 hits, 0 misses, so the fallback did not go away with a warm cache for me. I have not run that as a controlled A/B on a current tree, so treat it as an observation that doesn't yet match the warm-cache behaviour described on #690, not as a contradiction of it.

3. "A preferred existing thread for consolidating these DOOM observations?" — #690.

That is where @babyhuey's root-cause for the first-frame failure lives (first-dispatch shader compilation), along with the other Windows reports. I added a Windows data point there rather than open anything new: #690 (comment)

The four things your scope explicitly excludes, since you asked for exactly this. I won't repeat the detail that's already in the comment above, but to summarise what is verified here beyond startup:

• Rendering, visually confirmed — not a log inference. Menus, HUD and levels drawn correctly.
• Movement and firing — WASD movement, firing, weapon cycling on L1/R1, Q/E on keyboard. Mouse aiming works only after the cursor is captured; ToggleMouse (middle mouse) is host-side and never reaches the title, which is easy to mistake for broken mouse input.
• Audible audio — confirmed by listening, not just by audio: output open at 48000 Hz. No audio errors, warnings or unimplemented-export messages anywhere in the run.
• Sustained stability — a single session well past 30 minutes of process CPU time, reaching E1M3, returning to the menu, starting new games and using level select.

Plus one thing I didn't see covered anywhere: saves round-trip. The title writes /download0/doom1sav0.dsg (81,550 bytes) and reloads it on a later launch. It does not go through sceSaveData at all — it is plain libkernel POSIX I/O (sceKernelOpen with flags=0x601), and the file ends exactly on DOOM's 0x1d SAVEGAME_EOF byte with a coherent header, so the write is complete rather than truncated.

On the in-game rate: DOOM's own tic rate is 35 Hz, so a window title reading ~35 is the engine's cap rather than a fallback symptom — which is consistent with your 34.99 reading and worth knowing before treating it as a performance number.

AI-assisted: yes (Claude Code).

[Bitslay]

I was able to get it running at a stable 35FPS, including music, sound effects, movement, menus, hud, etc.

Adding a Windows / RTX 3060 gameplay to follow up on the CPU scaler observations, along with runtime notes from investigating the dispatch stall.

Attached is a screen recording of an active gameplay run on Windows (menus, rendering, movement, combat):
https://drive.google.com/file/d/1ywaovl6mGvf6g5EeyP0vS8acZ4pQkaXS/view?usp=sharing

1. General Runtime Improvements Tested

To rule out host synchronization stalls during startup and isolate presentation behavior, I tested two general runtime adjustments:

• Win32 scePthreadCreate synchronization (libkernel):
  On Windows hosts, guest thread creation handshakes using std::promise / std::future can intermittently stall under rapid worker thread spawning. Switching the creator/worker rendezvous to Win32 synchronization events (CreateEventW, SetEvent, WaitForSingleObject) eliminates these stalls across multi-threaded titles on Windows.
• SH register tracking for unannounced compute dispatches (libSceAgc):
  Titles that emit raw compute dispatches configure program base addresses directly via SH registers (0x20c/0x20d) without prior sceAgcCreateShader calls. Tracking these register updates in sceAgcCbSetShRegisterRangeDirect and ensuring the shader descriptor is synthesized prior to sceAgcCbDispatch prevents unhandled shader descriptor faults.

Changes are pushed to a clean branch on my fork for anyone testing or reviewing general AGC/kernel behavior:
Bitslay/AnyPS5:feat/doom-runtime-support

2. Observations on the CPU Scaler Fallback

Disassembly of the guest executable around 0x4fe8e confirms that the CPU scaler is an official, built-in fallback path within the port itself:

• The title polls scePadReadState during video initialization for 0x300 (L1 + R1). If held at boot, it explicitly logs video: L1+R1 held, using the CPU scaler and bypasses the AGC compute presenter immediately.
• This explains why CPU presentation runs reliably once the initial AGC compute presentation timeout triggers video: GPU presentation failed, switching to the CPU scaler.

AI-assisted: yes