Surround Sound Studio (PPSA99051) exits 3 s in since #5049 ("submission retirement failed")

Since #5049 (fix(shader): ignore unused descriptor fields for scalar buffer loads, merge c654b199b), Surround Sound Studio (PPSA99051, catalog release 01.000.003) exits about 3 s after start on Windows. Its own log (download0/hui/dev/app.log) ends with:

[ps5-agc] submission retirement failed; terminating application before cleanup

On the merge's first parent eecf90953 it starts, draws its menu, and keeps running. Through its menus it plays clips (Windows 11, RTX 5070, MinGW GCC 15, Release, 30 s runs driven by key presses).

git bisect --first-parent between 1209d3707 (good) and 131171e77 (bad) gave:

commit	result
`7963f16d1`	good
`eecf90953`	good
`c654b199b` (#5049)	bad: `submission retirement failed`
`23e93c054`, `1b127d4df`, `7d4f34c6e`, `23be5a02b`	bad

It's still bad on main 066b58fa1.

#5049 changes snapshot.buffers[i] in place in materializeTables: it clears bit 30 of word 1 and zeroes word 3 for buffers that only scalar loads use. I haven't narrowed down which of the title's shaders or submissions is affected. The title's "submission retirement" check runs in its own GL layer (the ps5-opengl stack PPSA99005 also uses), and it fails right after the first frames. One thing worth checking is whether the snapshot change reaches anything other than the scalar-only binding, such as a cached snapshot reused for another stage or draw.

AI-assisted: yes (Claude Code)

I traced the current path on main (f3434892b). ResourceMaterializer::Materialize builds a fresh nextSnapshot for the plan, and materializeTables normalizes that snapshot before it is stored in the per-shader ResourceCapture; captures are then exposed as shared_ptr<const ResourceCapture>. I do not see this normalization mutating a snapshot shared across stages or later draws. The remaining code-level possibility is that the failing shader was classified as scalar-only even though another path in that shader needs the descriptor fields that #5049 clears. Could you capture the failing shader address/stage and, if possible, the resource plan or SRT access for the descriptor? That would distinguish a classification gap from another cause in the title’s submission-retirement check.

I tested the exact first parent eecf90953 and merge c654b199b locally with Surround Sound Studio PPSA99051 release 01.000.003 (ZIP SHA256 fcb4e3cb794d36b30b9dee9ed86f0eea317e7c0071d193c18d9a07734e7beb69).

Windows 11, Ryzen 7 7800X3D, RTX 5070 / driver 617.14, WinLibs GCC 15.2, Release, SPIRV-Tools OFF. The same relinked executable, app data, GCC DLLs and input settings were used, with no input. GPU trace/profile logging was enabled in both runs. For the merge comparison, I retained the first parent's other runtime modules and replaced only the rebuilt AGC module, matching this merge's sole production-file change.

Build	Shader caching	Result
First parent `eecf90953`	Disabled	Same retirement failure, about 5.04 s
First parent `eecf90953`	Enabled	Same retirement failure, about 4.03 s
Merge `c654b199b`	Enabled, same cache directory	Same retirement failure, about 4.05 s

Both enabled-cache runs end during submission serial 3, after registration of the 21,652-byte pixel shader f8d1fab9, with [ps5-agc] submission retirement failed; terminating application before cleanup. Current main f3434892b, with only #5049's normalization removed locally, also reaches the same failure with shader caching disabled.

I therefore haven't reproduced the reported working pre-merge baseline or established a regression introduced by #5049. These results don't disprove your bisect; the difference between our setups remains unresolved. I also haven't established whether the unfinished submission is compiling, stuck or failed, so I am not claiming a compile-timeout cause or a verified fix.

Could you provide the exact build configuration, cache conditions and a GPU trace of the working parent versus the failing merge? In particular, was SPIRV-Tools enabled, and were both runs using equivalent shader/pipeline cache states?

@eljackjoestar-cmd

Thanks for testing, @eljackjoestar-cmd. I reran it to rule out cache state: the title's shader_cache (pipeline cache included) was deleted before every run, and only the library set changed between runs.

Setup:

Windows 11, RTX 5070 with driver 617.42.
WinLibs GCC 15.2.0 r7, CMAKE_BUILD_TYPE=Release, ANYPS5_ENABLE_SPIRV_TOOLS=OFF.
Both libraries folders are full builds of the exact commits, not a swapped AGC module.
Same relinked app.exe, no input, 40 s runs, no trace or profile variables.
Catalog release 01.000.003.

build	run 1	run 2
`eecf90953` (first parent)	still running at 40 s, no failure in `app.log`	same
`c654b199b` (#5049 merge)	exits 1 after 9 s, `submission retirement failed`	exits 1 after 8 s, same

So here it's deterministic with a cold cache on both sides. The visible differences from your setup are:

the driver (617.42 here, 617.14 there);
the full builds;
you had GPU trace/profile logging on, which changes timing.

If you'd like a specific trace from both commits, tell me the variables and I'll run them the same way.

A Linux data point, where #5049 is not what stops it: Ubuntu 24.04, RTX 4070 Ti, NVIDIA 595.99.02, GCC 13.3, Release, 30 s runs, catalog release 01.000.003. Homebrew UI Lab (PPSA99050), which uses the same GL stack, behaves the same.

Both titles end at 3–6 s with [ps5-agc] submission retirement failed on main 411e5e6, on main with fix(shader): ignore unused descriptor fields for scalar buffer loads #5049 reverted, and on fix(shader): ignore unused descriptor fields for scalar buffer loads #5049's first parent eecf90953.
With APS5_TRACE_GPU=1 APS5_DUMP_QUEUE=0, submissions 1 and 2 (a 4-vertex DRAW_INDEX_AUTO, then the end-of-submission RELEASE_MEM of 0x474c3301/0x474c3401) complete. Submission 3 reuses submission 1's buffer, draws 3 vertices with user SGPR 0 at 0, and never reaches its WAIT_REG_MEM. Its fence 0x474c3501 is never written, and the title gives up about 1.9 s later.
A gdb stop at the title's exit_group shows the AGC queue thread in Driver::draw → Graphics::CachedPipeline → LinkPipelineFromLibraries → NVIDIA's compiler (libnvidia-glvkspirv _nv002nvvm → libnvidia-gpucomp). With APS5_NO_GPL=1 it still fails, so the pipeline's shader compile takes longer than the title waits. A temporary timer around the fast link logs only the first pipeline's link (0.0 ms) before the exit.
The title's two largest shader-cache entries are 1.8 MB each: one fragment shader, 21,652 bytes of guest code per the title's own compile-shader log, becomes 445,980 SPIR-V words. Most of that is OpSelect (107k words), OpBitwiseAnd (104k), OpBitcast (55k) and integer compares. fix(shader): record a BDA lookup's fault from one call site #5814 (BDA lookup sites) does not change its size.
A warm start doesn't help: the title exits within 3–6 s and the Vulkan pipeline cache is saved every 10 s or at teardown, so the slow pipeline is never cached.

So at least on this machine the failure is a time budget: the title waits for a submission whose draw is still compiling a very large shader. If the same holds on Windows, #5049 could be what pushes that compile over the title's budget there, by changing that shader's code, rather than breaking the draw itself.

AI-assisted: yes

More on the Linux side. I think this explains both bisects: whether the title survives depends on NVIDIA's own shader cache, not on #5049's code.

The compile time. With temporary timers around vkCreateGraphicsPipelines, and an LD_PRELOAD shim that holds the title's exit for 25 s so the call can finish:

On main, the fragment-shader pipeline library for the 21,652-byte pixel shader takes 2,244–2,273 ms on an RTX 4070 Ti with 595.99.02. Every other library takes under 12 ms.
The title gives up about 1.9 s after submitting the draw that needs it.

NVIDIA's driver cache decides the result. These runs share one __GL_SHADER_DISK_CACHE_PATH, in this order (30 s runs, no input):

driver cache	`eecf90953` (first parent)	`main` `411e5e6`	`main` without #5049
empty	exits at 5 s	exits at 5 s	exits at 5 s
after one held-exit run of `eecf90953`	runs 30 s	exits at 5 s	exits at 5 s
then after one held-exit run of `main`	runs 30 s	runs 30 s	exits at 5 s

The slow compile never finishes inside the 1.9 s, so a normal run never caches it. Once anything caches it, that build keeps working. The cache entry only matches the exact module bytes. On this shader, #5049 changes one baked constant: the scalar-only buffer's descriptor word 3 goes from 0x30042fac to 0, with the size unchanged. So a driver cache that holds the parent's compile misses on #5049. On Windows that cache is under %LOCALAPPDATA%\NVIDIA\DXCache (or GLCache). Clearing it before both runs should make the parent fail too, if this is what happened.

What makes the shader slow. I dumped the request and replayed it offline with agc_shader_replay --prepare:

The shader's 5,413 code words become 445,980 SPIR-V words. Translating it takes about 2 s in the replay tool.
About 30% of those words come from the f32 NaN-result selection that nanResultF32 adds after each v_add/v_mul/v_fma_f32 (1910d14). With that selection skipped in a local build, the shader is 311,412 words and its library compiles in 1,219 ms. Both PPSA99051 and PPSA99050 then run 30 s with a cold cache.
Most of the rest is the exact denormal and NaN handling around each float op.
perf(shader): pick the f32 NaN result with one quiet and one fallback select #4287 brings the shader to 439,727 words (−1.4%). That isn't enough here: both titles still exit at 5 s.

I'm not suggesting dropping the NaN rule. That's a correctness choice. The real fix is probably to not compile at the first draw at all: build the fragment library when the shader is registered, or let the title's wait run while the pipeline compiles. I haven't tried either.

AI-assisted: yes

@milescoviello

AMD data point, where #5049 makes no difference either: Windows 11 (26300), Radeon 860M (RDNA 3.5, driver 32.0.13058.8001), WinLibs GCC 15.2.0, Release, catalog release 01.000.003 relinked with --windows --trap-sdk-syscall-stubs, 40 s per run.

Build	Empty run folder and caches (2 runs)	Same folder again, caches kept (2 runs)
`main` `eea428c`	exits at 4 s, 4 s	exits at 3 s, 3 s
`main` `eea428c` with #5049 (`c654b199b`) reverted	exits at 4 s, 4 s	exits at 3 s, 3 s

All eight runs exit with code 1 and end download0/hui/dev/app.log with [ps5-agc] submission retirement failed; terminating application before cleanup. The last shader the title compiles before that is the runtime's large pixel shader, compile-shader stage=5 ... bytes=21652 hash=f8d1fab9. That's the shader of #4399: on this GPU its pipeline link took 19.8 s there, against the runtime's 2 s retirement wait (2000 × sceKernelUsleep(1000)).

Keeping the caches doesn't help, because the title calls _Exit before the Vulkan pipeline cache (shader_cache/vk-pipelines-*.bin) is saved at teardown, so every run is a first run for that pipeline. That fits @milescoviello's finding that the outcome follows the pipeline caches (his NVIDIA shader cache) rather than #5049's code.

blackbearreloaded/ps5-opengl#12 raised that wait to 30 s (SDK 1.0.2). This catalog release predates it, so a rebuild of the title with the newer SDK should get past this regardless of the emulator.

AI-assisted: yes (Claude Code)

@milescoviello

On Windows I get the same answer: #5049 isn't what decides it. Builds from before #5049 fail the same way once NVIDIA's driver cache is cold.

Windows 11 Pro 26220, WinLibs MinGW-w64 GCC 15.2.0 r7, Release, NVIDIA RTX 4070 (driver 596.21), catalog release 01.000.003 relinked with --windows, no input, 40 s per run. Each run started from a new output folder (empty shader_cache) and a new, empty __GL_SHADER_DISK_CACHE_PATH; NVIDIA's Windows Vulkan driver writes its GLCache there.

build	cold driver cache
`c2565f014` (before #5049)	1 of 3 exit 1 (18 s)
`main` `6239ceffc`	3 of 5 exit 1 (10–32 s)
`main` `6239ceffc` with #5049's normalization removed locally	1 of 3 exit 1 (34 s)

Every failure ends download0/hui/dev/app.log right after compile-shader stage=5 ... bytes=21652 hash=f8d1fab9 with:

[ps5-agc] submission retirement failed; terminating application before cleanup

Runs that survive leave about 900 KB in the driver cache directory; failures leave about 100 KB, so a failed run never caches the slow pipeline. With the driver cache copied from a run that survived, 8 of 8 runs survived, including crossed pairs (main with a cache from c2565f014, and the reverse). The machine was busy during these runs, so the time to exit varies and the pass rates aren't a speed comparison between builds.

This matches @milescoviello's and @LeandroLP23's results: the outcome follows the driver cache and the first-run pipeline build of f8d1fab9 against the runtime's ~2 s wait (#4399), not #5049. My own run of this title on c2565f014 two days ago (1,733 frames in 60 s) had a warm driver cache from earlier runs. Looks like a duplicate of #4399 from here; the title-side fix is a catalog rebuild with the longer wait.

AI-assisted: yes (Claude Code)

Data point on NVIDIA Ada, Windows: RTX 4070 Laptop (driver 616.92), Windows 11, main 5d9dcc42d, catalog release 01.000.003 (SHA256 matches the one above), relinked with --windows, 40 s runs, new shader_cache for every run.

Driver cache	Runs	Result
new, empty `__GL_SHADER_DISK_CACHE_PATH` per run	3	all exit after 5–9 s with `submission retirement failed`
one `__GL_SHADER_DISK_CACHE_PATH` reused	4	all fail; the cache stays at ~103 KB
default `%LOCALAPPDATA%\NVIDIA\GLCache` (111 MB, populated by other titles)	3	all fail

So #5049 isn't what decides it here either, in line with the comments above.

Where the time goes (local instrumentation, not proposed for main): the slow part is the fragment-shader pipeline library of a 447,627-word SPIR-V module. With nanResultF32 bypassed in a local build it is 313,059 words (−30.1 %), the library is created in 1311 ms and 1460 ms cold, the title survives 40 s in 2 of 2 runs and the driver cache grows to 668 KB. With the NaN selection the library had not finished when the title aborted (runs of 3.8 s and 5 s), so I have no duration for that case.

The NaN tests are ~8.6k sites and each tests a distinct value (no duplicates to share), so I found no reduction that keeps the hardware-measured semantics, and I changed nothing in the recompiler.

Title side: ps5-opengl v1.0.2 raises the retirement wait to 30 s (blackbearreloaded/ps5-opengl#12, merged 2026-10-13), and release 01.000.003 (2026-10-09) predates it. A rebuild of the title with 1.0.2 should get past this.

Not tested: a warm driver cache that holds this compile, and a build from before #5049.

AI-assisted: yes (Claude Code).

Another title on this stack: Afterglow (PPSA47770, release 01.000.006, added to the catalog today).

Windows 11 Pro build 26300, Intel i7-11700F, NVIDIA GeForce RTX 3070, WinLibs GCC 15.2, Release, main 82ddae7, relinked with --windows, 40 s runs, a new output folder (empty shader_cache) each time. It exits by itself with code 1 after 12 to 21 s, with no message in the process's stderr. Its own log (download0/hui/dev/app.log) ends with:

[ps5-gallium] compile-shader stage=5 primitive=4 ... bytes=95468 hash=c6482fe5 ...
[src/Texture.cpp:1091 StorageTexture] StorageTexture address=0x220e00000 512x512 ...
[ps5-agc] submission retirement failed; terminating application before cleanup

How I found it (these are local tools, none of this is in a PR):

gdb on the running app.exe with handle SIGILL nostop: TerminateProcess(-1, 1) is reached from LibcTerminate_nid_no_patch called by _Exit_nid_postfix, and the return address after that is in app.exe (app.exe+0x1413292). So the title itself calls _Exit(1).
A local build of libc that dumps the last 64 traced library calls (APS5_TRACE_CALLS=all, relinked with --trace-imports) when LibcTerminate_nid_no_patch runs: the last five calls are sceKernelUsleep, clock_gettime, fwrite, fflush, _Exit. Over the whole run the counts are sceKernelUsleep 2,000 and clock_gettime 2,417, plus about 12.4 million memcpy and memset.
The one insertq (SSE4a) the title runs on this Intel CPU is emulated and is not the cause: with APS5_NO_SSE4A_EMULATION=1 the title faults 4 s in instead.

What I did not test: a warm NVIDIA driver cache, other GPUs, or whether the 95,468-byte shader's pipeline build time is what the title's deadline is waiting on. That comparison is the one milescoviello and screamm already made on Surround Sound Studio.

AI-assisted: yes

The Afterglow report adds another title that exits through the same submission retirement failed path, but it does not yet tie the 95,468-byte shader to the timed submission. This resembles #4399, where f8d1fab9 was traced through the title’s ~2 s wait to a slow cold pipeline-library build on several AMD/NVIDIA setups. Could you capture the final draw/submission number and shader hash, then time its pipeline-library creation (or confirm it is still in vkCreateGraphicsPipelines when _Exit runs)? Without that link I would treat this as a related symptom, not a separate fix candidate.

Update after reviewing the later reports against #4399: this does not look like a distinct #5049 regression or an AnyPS5-side submission bug. The same cold-cache failure is reproduced across NVIDIA/AMD and Windows/Linux; the failing draw compiles pixel shader f8d1fab9, and #4399 traces it to the ps5-opengl runtime's ~2 s retirement wait expiring during a long first pipeline build. Warm-cache runs pass that point, and the runtime's upstream 1.0.2 change raises the wait to 30 s; this catalog release predates it. Afterglow's similar exit is not yet tied to a specific submission or pipeline, so I would keep that as an unconfirmed related symptom.

I don't see a distinct AnyPS5 code change supported by this evidence. #4399 tracks the shared cause; a title rebuild with the newer runtime is the demonstrated path for this catalog version.

Agreed, and thanks to everyone who ran it: this was my error. I deleted AnyPS5's shader_cache between runs but not NVIDIA's own driver cache, so the pre-#5049 build kept hitting warm driver-cached pipelines while #5049's slightly different SPIR-V missed it. That reproduced a cold-cache slow build as a deterministic "regression". #4399 tracks the actual cause (the ps5-opengl runtime's 2 s retirement wait expiring during a long first pipeline build). Closing.

AI-assisted: yes (Claude Code)

Navigation Menu

Repository navigation

Surround Sound Studio (PPSA99051) exits 3 s in since #5049 ("submission retirement failed") #5876

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Surround Sound Studio (PPSA99051) exits 3 s in since #5049 ("submission retirement failed") #5876

Description

Activity

MarcZX10 commented on Oct 14, 2026

eljackjoestar-cmd commented on Oct 14, 2026

p3n1cillin commented on Oct 14, 2026

milescoviello commented on Oct 14, 2026

milescoviello commented on Oct 14, 2026

LeandroLP23 commented on Oct 14, 2026

screamm commented on Oct 14, 2026

nicolasabosch commented on Oct 16, 2026

DavidSamir commented on Oct 16, 2026

MarcZX10 commented on Oct 17, 2026

MarcZX10 commented on Oct 17, 2026

p3n1cillin commented on Oct 17, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions