Afterglow (PPSA47770)

[wrocketdev]

Existing thread

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

Title

Afterglow (PPSA47770)

Content version tested

01.000.006, homebrew catalog release PPSA47770.zip from DevvNirvana/afterglow (GPL-3.0), SHA-256 3c6d57ab42829577ccfde9a7f530ec8e3860e456f1c1244f93a1341d4969e47f, matching the catalog.

AnyPS5 commit

main at 9624d8c6bb9e, no pull requests applied.

System tested

Windows 11 Pro (build 26300), Intel Core i5-12600KF, NVIDIA GeForce RTX 3060 Ti (driver 617.42), WinLibs GCC 15.2.0 r7, Release.

Furthest point

Stops before the first frame

What is shown

The title exits with code 1 about 10 s after start, in 3 of 3 runs, before its UI appears. Its own log (download0/hui/dev/app.log; it reopens stdout there before main) ends with:

[ps5-gallium] compile-shader stage=1 primitive=4 ... bytes=160 hash=4c5aee55 ...
[ps5-gallium] compile-shader stage=5 primitive=4 ... bytes=95468 hash=c6482fe5 ...
[ps5-agc] submission retirement failed; terminating application before cleanup
[libc] _Exit(1) called from 00000000007540d8

Before that, the display opens, the clear submissions retire and all twelve fonts load. No NotImplemented and no unresolved import.

Current blocker

The same stop as #4399: Afterglow uses the ps5-opengl runtime, whose retirement wait gives up after about 2 s, while AnyPS5 builds the pipeline for the runtime's large pixel shader. This title's pixel shader is 95,468 bytes of guest code (c6482fe5), against 21,652 bytes for the f8d1fab9 shader in #4399.

The pipeline never reaches the cache: after three runs, pipelines.journal holds 1 pipeline, and each run fails the same way. Converting with --trap-sdk-syscall-stubs does not change it. The pipeline build time for this shader was not measured.

How it was run

eboot.bin and sce_module/libc.prx unwrapped with tools/unwrap_self.py and converted with relinker --windows --registry (through tools/audit_dump.py), and once more with --trap-sdk-syscall-stubs. Run from a folder with app0, libs (built from the same commit, with the WinLibs runtime DLLs), and empty data, download0 and temp0, with APS5_NO_PAD_INPUT=1; the shader cache was kept between runs.

AI-assisted: yes (Claude Code)

[root-over]

Linux / RADV data point. It's the same stop, and it only happens while the host driver's shader cache is cold.

Setup: Ubuntu, kernel 7.0, Ryzen 5 5625U iGPU (Vega/GCN 5, RADV RENOIR, Mesa 26.0.8), GCC 15.2.0, Release. main 8e68a7d7b with #10069 on top (it only changes the f32 denormal-preserve probe). Catalog 01.000.006 (SHA-256 matches), unwrapped and relinked with no options, 30–60 s per run.

Run	AnyPS5 shader cache	RADV disk cache	Result
first run after a rebuild	empty	cold for these pipelines	exit 1 after 15 s, submission retirement failed
6 runs, fresh run folder each time	empty	warm	alive at 30 s, every time
3 runs	warm	warm	alive at 60 s; first swap, ready splash_hidden=1, music playing
2 runs, MESA_SHADER_CACHE_DISABLE=true	empty	disabled	exit 1 after 15 s, both times

So the AnyPS5 side of the build (recompile plus the shader cache) fits in the 2 s here. The time that misses the wait is RADV compiling the big pixel shader. MESA_SHADER_CACHE_DISABLE=true reproduces it every time, which makes it a reliable way to test any change to that shader's size.

The exit comes from the title's own code. strace --seccomp-bpf -k -e trace=exit_group shows exit(1) called from the ps5-opengl retirement wait. In that loop the runtime spins for 200 ms, then calls sceKernelUsleep(1000) up to 2000 times. Then it prints the message and exits.

The recompiled module for that shader is large. The biggest cache entry is 7.5 MB, with 1,858,745 SPIR-V words and 379,904 instructions (ID bound 343,594). The most frequent opcodes are:

Opcode	Count
OpBitwiseAnd	75,555
OpSelect	72,354
OpBitcast	59,888
OpINotEqual	36,466
OpDecorate	36,023
OpFMul	21,714

I'm looking at whether the recompiler can emit less for this shape.

[root-over]

Follow-up on the module size, same machine (Vega/GCN 5, RADV, Mesa 26.0.8). These are local experiments, not proposals.

Every run starts with an empty AnyPS5 shader cache and MESA_SHADER_CACHE_DISABLE=true, two runs per row. The size is the largest shader cache entry.

Variant	Largest entry	Cold first run
main	7.5 MB	exit 1 after ~15 s (submission retirement failed)
hardware f32 flush forced on	5.4 MB	exit 1
nanResultF32 bypassed (no RDNA NaN propagation emulation)	5.2 MB	exit 1
both	2.7 MB	first swap, alive at 40 s

So on this GPU the module is about 64% emulation: the f32 denormal flush and the RDNA NaN propagation. Removing both brings the pipeline under the runtime's ~2.2 s wait.

On this device, neither emulation can be removed correctly:

• Flush. The flush probe reports 6 of 5472 here. All 6 are v_fma_f32/v_fmac_f32 in lane 20 of the mixed program: 0x1fffffff * 0x1fffffff + 0x00800000 gives 0x00ffffff emulated and 0x00800000 with DenormFlushToZero. RADV on GFX9 never emits v_fma_f32 for these shaders: the NIR has no ffma, only fmul/fadd pairs that ACO fuses into v_mad_f32/v_mac_f32. That holds even with NoContraction, and Vulkan allows it, since Fma's precision is inherited from OpFMul + OpFAdd. Under FTZ the tiny intermediate product is therefore flushed, so the probe is right to keep the emulation.
• NaN. With nanResultF32 bypassed, agc_driver_f32_arithmetic_nan fails on RADV: v_fmamk_f32 returns 0x7fc00000 where RDNA keeps the 0x7f812345 payload.

I also counted pure instructions in the module that repeat with the same opcode and operands. That's 2,219 of 338,582 (0.65%), so there's no easy CSE win either.

On a device whose flush probe passes, the NaN emulation alone is about 30% of this shader. The reported RTX 3060 Ti run may be in that position.