PS5LM Plus (PPSA99581)

[babyhuey]

Existing thread

• I searched this category for the title ID and no thread exists for this title on any platform.

Title

PS5LM Plus (PPSA99581)

Content version tested

0.8.3 (catalog release)

AnyPS5 commit

main feddf7f / ce5c839, alone and with #5605 (sceKernelGetSocPowerConsumption).

System tested

• Windows: Windows 11 Pro 25H2 (26200.9457), RTX 3080 (NVIDIA 591.86), WinLibs GCC 15.2.0 r7, Release
• Linux: Ubuntu 24.04, GCC 13, headless (SDL offscreen driver)

Furthest point

Stops before the first frame

What is shown

Nothing on screen. On main it doesn't load: its one absent import is CA5jcDb2vYI (sceKernelGetSocPowerConsumption) from libkernel.prx. With that export it loads and starts, then dies right away on host standard-output handling: FileStream: closed stream on Linux, and on Windows three UCRT invalid parameter reports, then Formatted output write failed (WindowsFormatting.hpp PrintWindows). It looks like the title closes or replaces stdout early and then prints to it; not yet traced.

Current blocker

1. feat(libkernel): export sceKernelGetSocPowerConsumption #5605 (sceKernelGetSocPowerConsumption) merged 2026-10-14. On main 63fb0cd the title now stops at the next item (Linux: FileStream: closed stream, 0.5 s in).

2. fix(libc): fail stream calls on a stream that a failed freopen closed #5632 merged 2026-10-15: the title's freopen of stdout and stderr to /data/PS5LM/app.log fails because the directory doesn't exist, and AnyPS5 threw on the later writes. With feat(libkernel): export sceKernelGetSocPowerConsumption #5605 and fix(libc): fail stream calls on a stream that a failed freopen closed #5632 it reaches its UI on Windows and stops for user data (no .gguf models).

3. fix(libc): keep the host standard stream when a guest freopen of it fails #5668 merged 2026-10-18 (f03a2da5e): the failed freopen also closed the host's own stdout, so on Windows every host log line tripped the UCRT invalid-parameter handler and it ran at about one frame. With feat(libkernel): export sceKernelGetSocPowerConsumption #5605, fix(libc): fail stream calls on a stream that a failed freopen closed #5632 and fix(libc): keep the host standard stream when a guest freopen of it fails #5668 it runs its full dashboard at 59.94 fps on Windows, waiting for a model.

4. Update 2026-10-18: PS5LM Plus 0.8.4 (current catalog release) creates /data/PS5LM itself, so it no longer reaches the failed freopen; PS5LM 0.9.0 (PPSA99575) still does and is covered by fix(libc): keep the host standard stream when a guest freopen of it fails #5668. With a model loaded, the GPU output depends on fix(shader): share wave64 VGPRs past the private ones between the two halves #7410 (wave64 shared VGPRs, see the comments below), and the CPU backend needs file mmap on Windows (feat(libkernel): map regular files with mmap on Windows #6542).

How it was run

The catalog eboot.bin unwrapped and relinked (--windows on Windows), run from a folder with app0 and an empty data folder, 30 to 60 s per run.

[wachi35676]

Update on main bd56fa6fd (Windows 11, Ryzen 5 9600X, RTX 5070 Ti / NVIDIA 617.42, WinLibs GCC 15.2.0, Release), PS5LM Plus 0.8.4 from the author's release. Test model: Qwen2.5-0.5B-Instruct q4_k_m from Qwen's official Hugging Face repo (Apache-2.0). Completions were requested over HTTP on port 8081 with "The capital of France is", n_predict 16, temperature 0.

Library "Load" relaunch: works in 3 of 3 runs, now that #6237 is merged. On 922dc8999 it ended in 3 of 3 runs with [libc] unhandled exception '15ProcessShutdown' and FATAL: abort() (SIGABRT) at sceSystemServiceLoadExec("/app0/eboot.bin"). The model then loads (llama_server: model loaded) and the server answers.

GPU output is wrong with the title's default plan (-fa on -ctk q8_0 -ctv q8_0). The answer is orntymology. In the 19th-arthury.10 on every run, and it is deterministic. The CPU backend in the same binary (-dev none -ngl 0, same KV settings) answers Paris. …. Narrowed:

Setting	Output
flash attention off	correct
flash attention on, K/V f16	correct
K q8_0, V f16	correct, also with GGML_VK_DISABLE_INTEGER_DOT_PRODUCT=1
V q8_0, q4_0 or q5_0 under flash attention	wrong

• The same happens on the AMD Radeon iGPU (ANYPS5_GPU=AMD), with different garbage.
• None of APS5_SPIRV_OPT=none, APS5_NO_WINDOW_NARROWING=1, APS5_BDA_BYTE_READS=1, APS5_STORE_AT_LABEL=1, GGML_VK_FA_SPARSE_DISABLE=1 or GGML_VK_DISABLE_F16=1 changes it.
• The V-dequant path of the flash-attention shaders that differ uses buffer_load_short_d16, v_alignbyte_b32, v_cvt_f16_i16_sdwa (sext BYTE_n to WORD_n, preserve), v_pk_mul_f16 and v_pk_fma_f16 with op_sel:[0,1,0], and one v_cvt_f16_f32_sdwa (WORD_1, preserve).
• Root cause not found yet. Running with -ctv f16 is a workaround.

CPU backend: llama_model_load: error loading model: mmap failed: Operation not supported. On Windows, mmap of regular files needs #6542. The model is not a multiple of 16 KiB long, so the mapping also extends past the end of the file, which #6542 doesn't cover yet; I'm extending it.

A cold shader cache gave ggml_vulkan: device lost twice (at 35 s and 63 s), which looks like the long pipeline builds of #6118 / #4399. Warm runs didn't show it.

AI-assisted: yes (Claude Code); results above were run on this machine.

[wachi35676]

Follow-up: the garbage with the default -fa on -ctk q8_0 -ctv q8_0 plan comes from wave64 shared VGPRs, not from the q8_0 dequantization. Fix: #7410.

The title's RADV/ACO shaders end their wave64 reductions by swapping the two halves of the wave through shared VGPRs. v56/v57 are written with row_mask:0x3/0xc and read back the other way, which is ACO's emit_permlane64_shared_vgpr. The flash-attention dispatch declares them: COMPUTE_PGM_RSRC1 = 0x402c000d (56 private VGPRs), COMPUTE_PGM_RSRC3 = 0x2 (16 shared).

AnyPS5 kept those registers private, so the reductions lost the other half's partial sums. I replayed the layer-0 prefill FA dispatch against a numpy reference: every key column with index mod 8 in 4..7 was missing from the output, the row sum and the row max.

With #7410 on Windows 11 / RTX 5070 Ti, the default plan answers Paris. It is the largest city in Europe and the second largest in the world in 3 of 3 runs, the CPU backend's exact output. Before it was orntymology. In the 19th-arthury.10. -fa on with f16 K/V and -fa off now give the same text; before, they were slightly off.

On the AMD Radeon iGPU (ANYPS5_GPU=AMD) the title is still garbage in every configuration, -fa off included, with and without the fix. That is a separate bug; only the replayed FA dispatch is correct on that GPU.

AI-assisted: yes (Claude Code); results above were run on this machine.

[wachi35676]

Status of PS5LM Plus GPU output, with three open PRs, all from me:

• fix(shader): share wave64 VGPRs past the private ones between the two halves #7410 (wave64 shared VGPRs): the root cause of the garbage on NVIDIA. With it, NVIDIA gives the CPU backend's exact answer with and without flash attention.
• fix(shader): order wave LDS accesses with a memory barrier on AMD's proprietary driver #8134 (AMD proprietary driver: subgroup barrier compiled to s_barrier): fixes AMD RDNA 2 with flash attention off. Three other people have confirmed it on other RDNA 2 devices (driver 32.0.21045.5002).
• fix(shader): widen LDS atomic fences to device scope on AMD's proprietary driver #8489 (AMD proprietary driver: workgroup memory fence after LDS atomics compiled to s_barrier): fixes AMD RDNA 2 with flash attention on. It's stacked on fix(shader): order wave LDS accesses with a memory barrier on AMD's proprietary driver #8134.

With all three merged together, on Windows 11 with an AMD Radeon RDNA 2 iGPU (1002:13c0, driver 32.0.21042.62), PS5LM Plus 0.8.4 and Qwen2.5-0.5B-Instruct q4_k_m (prompt "The capital of France is", temperature 0, 16 tokens), the answer is " Paris. It is the largest city in Europe and the second largest in the world" in each case:

• flash attention on, q8_0 cache: 3 of 3 runs;
• flash attention on, f16 cache: 4 of 4 runs;
• flash attention off: 4 of 4 runs.

That is the CPU backend's text. Without #8489, flash attention on produces different garbage on every run.

LeandroLP23 reported that an RDNA 3.5 Radeon 860M (driver 32.0.13058.8001) doesn't show the AMD problems. A cold shader cache can still hit the title's 10 s fence timeout on the first run of each configuration; the runs above used a warmed cache.

AI-assisted: yes (Claude Code); results above were run on this machine.