docs: record DOOM homebrew integration compatibility

[nicolasabosch]

What

Add DOOM Shareware homebrew PPSA99666 01.001.000 to the tested compatibility list. Record the verified Windows 11 / RTX 4070 E1M1 result, movement and shooting, and the pending integration requirements (#553, #683, #684 and #685). The entry explicitly describes an integration build rather than claiming current main can run the title.

Document the observed cold-start CPU scaler fallback and nonterminating startup diagnostic. Leave Linux and untested hardware unknown; audible audio and extended gameplay were not verified. Link the actual gameplay captures from #685 without adding image files to the repository.

Tested

Documentation only. Reviewed against the previously completed integration run and its logs/screenshots; checked the Markdown table column count and ran git diff --check. No new runtime tests or performance benchmark performed for this documentation change.

In-game screenshots

Final integration build, E1M1:

After movement and shooting:

Checklist

• Based on current main af92452; no open PR changes COMPATIBILITY.md
• One documentation topic; new PR
• No code comments or runtime changes
• No investigation files, images or logs added to the repository
• No third-party code added
• Depends on: none for this documentation change; the documented game run requires feat(userservice): implement foreground user, registered list, user colour and NP account id #553, feat(libs): implement homebrew libc and kernel runtime exports #683, fix(relinker): bind Windows imports to their declared modules #684 and feat(agc): support version initialization and raw compute programs #685
• AI-assisted: yes

[NahuelGenchi]

Hi @nicolasabosch, I'd like to try this DOOM Shareware homebrew on Linux with an older AMD card (R9 380, GCN, RADV), since that column is still unknown. Where did you get the PPSA99666 package from? Is it a public homebrew release or something you built yourself? If there's a source repo or a release link I can use, I'll report back how it goes on Linux.

[adriadam10]

Thanks for documenting this. A few things to fix before it can go in:

• docs/user/COMPATIBILITY.md:8 says #553, #683, #684 and #685 "are not yet merged into main", but all four are merged now (#553 on 10-06, #683 and #685 on 10-06, #684 on 10-07). The paragraph and the "pending dependencies" status in the table row (line 6) are out of date.
• Please re-run the title on current main and record that result instead of the integration build, or say plainly which build you tested. Drop the dependency list if it no longer applies.
• @NahuelGenchi asked where the PPSA99666 package comes from. Please answer on this PR and, if there is a public source, link it in the entry, so others can reproduce the result.
• The cold-start CPU scaler fallback and the UCRT invalid-parameter diagnostic: if they still happen on main, open an issue and link it; if they don't, remove the paragraph.

We can't run Windows/NVIDIA here, so the Windows result itself is not verified on our side.

[hikazey]

Linux result for the entry, in case it's useful (DOOM Shareware PPSA99666, release v1.1.1 / content version 01.001.001):

• Reaches E1M1 on Linux. It needs main 0e173a46 + feat(libkernel): implement poll for guest sockets #1278 + fix(libkernel): accept MSG_NOSIGNAL in send and sendto #1279 + fix(libkernel): translate scalar POSIX I/O errors #1307 and a relink with --exclude-sce-module libc.prx. Without that flag the bundled loader shim's placeholder exports break snprintf, and the launcher finds no WAD (Linux: a bundled libc.prx loader shim (ps5-native-app-boilerplate) binds libc imports to placeholder exports; DOOM PPSA99666 finds no WAD #1497). The launcher shows "DOOM Shareware: Episode 1", and in E1M1 moving and firing work (ammo 50 → 48).
• Performance (Ubuntu 24.04 container on a Ryzen 9 5900X, Xvfb, no GPU; Mesa llvmpipe for Vulkan):
  • launcher: 59.94 FPS
  • in game: 35.00 FPS, DOOM's tic rate, steady over 30 s while moving and turning
  • CPU: about 2.1 cores
• The cold-start CPU scaler fallback this entry documents happens on Linux too (gpu: frame 1 never completed, then video: GPU presentation failed, switching to the CPU scaler). Here that's with llvmpipe; not tested with a hardware GPU on Linux.
• Not tested: audio (dummy SDL driver) and extended gameplay.
• /download0 must exist beside the executable. Otherwise the title's log open fails and, before fix(libkernel): translate scalar POSIX I/O errors #1307, its WAD scan aborts.

AI-assisted: yes (Claude Code).

[MarcZX10]

Additional reproducibility details from #1497: the public source for PPSA99666 is lowbit/ps5-doom, release v1.1.1 (content version 01.001.001). A Linux run reached E1M1 on main 0e173a46 plus #1278, #1279 and #1307, using --exclude-sce-module libc.prx; movement and firing worked. That run used llvmpipe in an Ubuntu 24.04 container, so it does not establish Linux hardware-GPU performance. The CPU-scaler fallback was observed there after the first AGC frame did not complete.

For the compatibility entry, distinguish that Linux v1.1.1 run from the Windows integration run for version 01.001.000. #553, #683, #684, #685, #1278 and #1279 are merged; #1307 is still open, so the Linux result is not a current-main-only run. I can't verify a Windows run on current main from the evidence in this PR.

[babyhuey]

The cold-start CPU scaler fallback comes from the presentation kernel being compiled at its first dispatch. Measured on Windows 11, RTX 3080, main d70b899, GPU otherwise idle:

run	shader disk cache	presentation	title FPS
1 (cold)	0 hits, 1 miss, 1 write	gpu: frame 1 never completed, then video: GPU presentation failed, switching to the CPU scaler	59.9
2 (same work dir)	1 hit, 0 misses	AGC compute presentation, no fallback	43.6
3 (same work dir)	1 hit, 0 misses	AGC compute presentation, no fallback	40.1

Run 1 also logs Compute shader 0x202a81800 was not registered; preparing its artifact at dispatch, so the first frame waits on that compile and DOOM's frame 1 wait expires first. With the artifact in shader_cache, the same kernel completes and the title stays on GPU presentation. No BDA, import or write-back errors appear in any of the three runs, so this is separate from the Linux /dev/udmabuf case in #1688. The title screen renders correctly in all three.

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
#2055	docs/user/COMPATIBILITY.md L5

[ycbuzi]

Another Windows data point, aimed at the two things this entry lists as unverified: save/load and extended gameplay. This was an integration build, not current main — main 2edaf7f4 plus a local stack of open PRs — on Windows 11, RTX 4070 SUPER, with a DualSense connected. DOOM Shareware PPSA99666, release v1.1.1 (content version 01.001.001).

Save/load round-trips. The title wrote /download0/doom1sav0.dsg (81,550 bytes) and reloaded it on a later launch. The write does not go through sceSaveData at all — it is plain libkernel POSIX I/O:

[sceKernelOpen] path=/download0/doom1sav0.dsg flags=0x601   (O_WRONLY|O_CREAT|O_TRUNC)

Before that, the save menu probes slots 0–5 read-only (flags=0x0) to populate the slot descriptions. The resulting file is structurally complete rather than truncated: it ends exactly on DOOM's 0x1d SAVEGAME_EOF byte, and the header decodes coherently — 24-byte description, a version 110 string matching the running v1.10 build, then skill, episode/map and the playeringame flags.

Extended gameplay. Beyond E1M1: reached further maps, cycled weapons on L1/R1, returned to the main menu, started new games and used level select. Input mapped correctly across DualSense and keyboard/mouse. Note that ToggleMouse (middle mouse) is host-side and never reaches the title, so the cursor has to be captured before mouse aiming works — easy to mistake for broken mouse input.

Audio is audible and works. Confirmed by listening over a long session (~33 min of process CPU time, still running at the time of writing). libSceAudioOut opens the device at 48000 Hz and DOOM's own mixer initialises (S_Init: Setting up sound, S_Init: default sfx volume 8), with no audio errors, warnings or unimplemented-export messages anywhere in the run.

Cold-start CPU-scaler fallback reproduces exactly as @babyhuey describes, on the same presentation kernel address:

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

In-game sits at DOOM's 35 FPS tic rate. I have not yet re-measured with a warm shader_cache on this machine to confirm the no-fallback second run, so treat that as unverified here rather than as independent confirmation.

Edited to correct the audio line: this comment originally listed audible audio as not verified. It has since been confirmed by listening, with the log corroboration quoted above.

AI-assisted: yes (Claude Code).

[adriadam10]

Thanks for the entry. The points from the previous review were still open, so I pushed one commit on top of your branch fixing them in docs/user/COMPATIBILITY.md:

• Removed the "not yet merged" text and the "pending dependencies" status: #553, #683, #684 and #685 are merged. The first Windows result is labelled as an integration build of version 01.001.000.
• Added the package source (lowbit/ps5-doom, v1.1.1), answering @NahuelGenchi's question.
• Added the results reported in this thread: Linux/llvmpipe E1M1 (@hikazey, @MarcZX100; it still needs the open #1307), and Windows RTX 4070 SUPER further maps, save/load and audio (@ycbuzi).
• Kept the cold-start CPU scaler fallback, now with the cause measured by @babyhuey, since it still reproduces on recent main. Removed the UCRT diagnostic note: nobody reports it on main.

Docs only; the game results are the reporters', not re-run here. Merging once CI is green.