AGC: PS5 FSR4 Showcase (PPSA99011) gives up in its first FSR4 pass while the queue worker builds 130k-800k-word compute pipelines (up to 66 s each on AMD)

@YossiYad

Update: the cause is the build time of the FSR4 compute pipelines on the queue worker, not a lost label write; measurements in #6118 (comment). With all of them cached the title gets past this stage and stops at stage=compose.

PS5 FSR4 Showcase (PPSA99011, catalog 01.000.010) gets through start-up on main plus #5648 (with #5163 and #5477, now merged, it needs nothing else). It builds its pipelines, reaches chapter 0, and then loses its Vulkan device in the first FSR4 pass:

FSR4_SHOWCASE_SUBMIT probe_ms=1.69 single=0
FSR4_SHOWCASE_CHAPTER index=0 title=FSR 4 on PlayStation 5
FSR4_SHOWCASE_ERROR fence=-4 stage=fsr4 after_ms=4525
FSR4_SHOWCASE_END result=FAIL

Where -4 comes from. The title doesn't use AGC directly. It runs on the Vulkan driver bundled with the SDK (blackbearreloaded/ps5-fsr4, external/ps5-vulkan = mpereiraesaa/ps5-vulkan at 4bb0c8b). There vkWaitForFences (10 s timeout in examples/fsr4_showcase/main.c) gets VK_ERROR_DEVICE_LOST from the queue poll. The compute path in native/queue_ps5.c submits a chain of dispatches and then spins on a 64-bit label until it reads the token (serial << 32) | last. It gives up with VK_ERROR_DEVICE_LOST when:

the label holds another job's serial or an index past last; or
the wait exceeds 3 s + 0.1 s × (last - first).

4525 ms is that budget for a chain of about 15 dispatches. So the chain's last token is never seen within the budget. Either the label write after the final dispatch doesn't land, or the chain takes more than 4.5 s. It also checks that readback[3] (set to 0xdeadbeef before the submit) was cleared by the GPU.

Seen on two GPUs and both host OSes:

Setup	Result
Windows 11 (26300), Radeon 860M (RDNA 3.5, driver 32.0.13058.8001), `main` `eea428c` + #5648 `943d362d2`	1 run `fence=-4 stage=fsr4 after_ms=4525`; 1 run `vkQueueSubmit(queue, 1, &s, fence) = -4` at 14 s
Same machine, `main` `d8888df` + #5163 + #5477 + #5648 (#5648 comment)	4 of 5 runs `after_ms=4525`/`4526`, the fifth `vkQueueSubmit` -4; the same with warm shader caches, so not the compile time
Linux, RX 7700 XT, RADV (@YossiYad on #5648)	`fence=-4 stage=fsr4 after_ms=4513`

The emulator logs nothing for it: no AGC error, no throw. Just before, it prepares 13 compute shaders at dispatch (Compute shader 0x2754…0000 was not registered; preparing its artifact at dispatch).

Possibly related: #5437 (XPSemu), where label writes after a dispatch never satisfy a WAIT_REG_MEM in the same submission.

I'm looking into the next stop (stage=compose).

AI-assisted: yes (Claude Code)

@YossiYad

Correction to the description: the label isn't lost. The chain runs out of the title's budget because the queue worker is still building its compute pipelines.

What the queue worker does during the wait. gdb 2 s into chapter 0 shows the queue worker 0x0 thread inside amdvlk64, called from AgcDriver::VulkanDevice::computePipeline. APS5_PROFILE_DRAW=1 logs each build. Here is the first run after the earlier ones had already cached the small pipelines:

[dispatch] created a pipeline for 794502 SPIR-V words in 11 ms (program 0x275560000)
[dispatch] creating a pipeline for 796524 SPIR-V words (program 0x275580000)
FSR4_SHOWCASE_ERROR fence=-4 stage=fsr4 after_ms=4528
[dispatch] created a pipeline for 796524 SPIR-V words in 52402 ms (program 0x275580000)

Each run caches one more slow pipeline. The build that outlives the title's 4.5 s still finishes, and [pipeline-cache] saved ... (merged ...) keeps it at teardown, so the next run gets one pipeline further. Uncached builds on the Radeon 860M (Windows, driver 32.0.13058.8001), one per run:

SPIR-V words	build time
796,524	52.4 s
794,551	65.9 s
657,804	24.0 s
391,143	10.1 s
390,771	9.8 s
340,982	3.9 s
299,091	8.3 s
267,640	5.2 s
131,187	0.9 s

That's about 3 minutes of pipeline builds for the FSR4 pass, against the title's 3 s + 0.1 s × dispatches budget per submission (native/queue_ps5.c). Once cached, each builds in 5–11 ms.

After 7 runs the FSR4 stage passes. With every pipeline in the cache (a run with no build over 100 ms), the title gets past stage=fsr4 and stops at the next stage:

FSR4_SHOWCASE_CHAPTER index=0 title=FSR 4 on PlayStation 5
FSR4_SHOWCASE_ERROR fence=-4 stage=compose after_ms=682

682 ms is inside any budget, so this one is a different device-lost condition in ps5-vulkan's graphics path. The emulator logs no error for it. I'm looking at that next.

So the first stop is the same kind of cost as #4399 (a 496,697-word pixel shader, 19.8 s to link here) and #4977 (vkQuake, 519,500 words): very large recompiled modules, built synchronously at the dispatch that first uses them. The title gives up long before a first run can finish them, so only repeated runs with a persistent shader_cache get past it. I haven't measured RADV's build times for these modules (@YossiYad's Linux run stops at the same point, after 4513 ms).

Setup for all of the above: Windows 11 (26300), WinLibs GCC 15.2.0, Release, main eea428c + #5648, the same run folder reused between runs (shader_cache kept), APS5_PROFILE_DRAW=1.

AI-assisted: yes (Claude Code)

This looks directly relevant to open PR #5925: it adds submission lookahead that builds both graphics and compute pipelines on a worker pool before their packets execute. The PR’s summary says it walks compute dispatches as well as draws, and includes a submit-lookahead fixture. I have not verified the FSR4 Showcase trace against that branch, so I would treat it as a candidate fix rather than a confirmed one. The issue’s large first-use compute builds (up to 65.9 s) seem like a useful workload for the author/reporter to compare with the PR.

@YossiYad

Update on the next stop: stage=compose is the register-defaults table, fixed by #6270 (@YossiYad). With it, on the warm cache, the title plays chapters 0–2 on the Radeon 860M. It then stops in chapter 2 on the same pipeline build time this issue describes: a 299,294-word compute pipeline that wasn't cached yet took 11.3 s. Details in #6270 (comment). @MarcZX100's pointer to #5925 (building a submission's pipelines ahead on a compile pool) is the candidate for that part; I haven't tried it yet.

Tried #5925 (with #5875) on this title: it doesn't save the first run, since every one of these builds is longer than the title's budget even in parallel. But the cache warms much faster: past stage=fsr4 on the fourth run, against still stuck after nine with both features off on the same build. Numbers in #5925 (comment).

Another title in this class, with a graphics pipeline on NVIDIA: Afterglow (PPSA47770, catalog 01.000.006). Windows 11, RTX 3080, WinLibs GCC 15.2, Release, main 13e48ed29.

Stop: after five queue-0 submissions it exits 1 within about 5 s. Its own log (download0/hui/dev/app.log) ends with [ps5-agc] submission retirement failed; terminating application before cleanup, then _Exit(1). Afterglow pins ps5-opengl SDK 1.0.0 (its tools/fetch-opengl-sdk.sh), whose retirement wait is about 2 s.
What the wait is on: submission 5 ends with the runtime's marker, RELEASE_MEM data_sel 2 to 0x21ea7eff0, value 0x474c3701. Its draw needs LinkPipelineFromLibraries, and the fragment-shader library (a 95,468-byte pixel shader) is compiled inside NVIDIA's driver: VkPipelineCreationFeedback cache hit 0, driver duration 37.42 s. The label commit queued behind that draw on the pipeline committer runs only after it. With the guest's _Exit held open, the marker lands 37.47 s after the packet; the final link takes 0.3 ms. So even SDK 1.0.2's 30 s budget would miss it on a cold cache. APS5_PIPELINE_DRAIN_LABELS=1 doesn't change it, because the block is the draw ahead of the label.
It never warms by itself. The title exits before the 37 s compile finishes, so nothing is stored in the pipeline cache, the journal or NVIDIA's disk cache. Every later run is cold again, unlike the gradual warm-up described above for FSR4. After one run held open long enough to finish the compile, the next run hits the cache (that library in 15.7 ms) and runs the full 60 s at 35-40 FPS, drawing its first screen (the flashing-lights warning card). Pointing __GL_SHADER_DISK_CACHE_PATH at a new directory and clearing AnyPS5's shader_cache reproduces the cold failure (exit 1 at 11.6 s).

A compile pool alone wouldn't save this one, since the single build is longer than either budget. Two things might: letting labels that don't depend on the draw commit ahead of it, or finishing and storing an in-flight pipeline build when the guest exits, so that the next run is warm.

AI-assisted: yes

An update on current main (0d1c299a9, which has #6270 and #5648): the stop described here still comes first, the cache-filling runs get past it, and the next stop is at chapter 2.

Radeon 860M, driver 32.0.13058.8001, Windows 11 26300, WinLibs GCC 15.2.0 r7, Release. Repeated runs in one run folder, so shader_cache and the pipeline cache are kept between runs.

The first runs stop as above: FSR4_SHOWCASE_ERROR fence=-4 stage=fsr4 after_ms=4522 in chapter 0, 4521 to 4523 ms every time. Runs need to last long enough for the slow build in progress to finish after the title gives up: some runs took 42 to 69 s before exiting. With 50 s runs the slowest builds never reached the cache. Over the longer runs the pipeline cache grew from 480 KiB to 2400 KiB, and the shader disk cache went from 6 to 17 hits.

After about ten runs chapter 0 passes and the title goes on:

FSR4_SHOWCASE_CHAPTER index=0 title=FSR 4 on PlayStation 5
FSR4_SHOWCASE_SPLASH hidden=00000000
FSR4_SHOWCASE_CHAPTER index=1 title=Against a bilinear upscale
FSR4_SHOWCASE_CHAPTER index=2 title=One pixel in nine
FSR4_SHOWCASE_ERROR vkQueueSubmit(queue, 1, &s, fence) = -4
FSR4_SHOWCASE_END result=FAIL

Chapter 2 stops the same way in 5 runs of 5 after that, and the caches no longer grow, so this looks like a different stop from the build-time budget. AnyPS5 prints nothing for it: no what(), DEVICE_LOST or has not reached submission line. Unlike the stage messages above, it is vkQueueSubmit itself returning -4.

#6270 reported chapters 0 to 6 at about 25 FPS on an earlier main with the pipelines cached, so chapter 2 may be new since then, or specific to this GPU. I haven't looked into it yet.

AI-assisted

Another title in this class: vkQuake (PPSA99010, mihawk-99 1.0), on main 07377573f, Windows 11. Its data is the shareware id1/pak0.pak, from id's freely redistributable quake106 release.

On demo1 it stops 3 of 3 runs on an RTX 5070 Ti, and 1 of 1 on the Radeon iGPU (ANYPS5_GPU=AMD):

vkDeviceWaitIdle -> -4
radv/ps5: the GPU has not reached submission 17 (at 16) in 10 s
QUAKE ERROR: vkWaitForFences failed with code -4

gdb samples show queue worker 0x0 inside VulkanDevice::createComputePipeline (NVIDIA nvgpucomp64.dll) throughout. The pipeline is compute 0x20bf7f400, whose 2748 code words recompile to 408,184 SPIR-V words:

OpSelect: 69k words
OpBitwiseAnd: 64k
OpUGreaterThan + OpIEqual: 43k
1,353 OpFunctionCall

The build didn't finish within a 120 s run. The title exits first, so the cache never warms.

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

Follow-up on vkQuake (PPSA99010), measured on main c1ca83479, Windows 11, RTX 5070 Ti and the Radeon iGPU. On NVIDIA, the SPIR-V word count isn't what makes these builds slow.

Where the 408,184 words of compute pipeline 0x20bf7f400 come from. These were counted by tagging each IR value with the GCN instruction that produced it. The module was captured with APS5_DUMP_SHADERS and replayed with agc_shader_replay.

About 55% comes from f32 add/mul/fma/mac. The rest is mainly flat/global (BDA) memory at 26% and f32 min/max at 9%.
Removing the f32 constructs one at a time shows how much each adds:
- NaN-result emulation: 91k words
- flushTinyProduct: 54k
- input/output denormal flushes: 44k
- min/max NaN and zero handling: 15k
Together they are 227k of the 408k. This GPU doesn't use perf(shader): flush f32 denormals in hardware when a startup probe matches the emulation #6503's hardware flush; its probe doesn't run here. On the AMD iGPU (one-lane wave64, hardware FTZ), the same program is 159k words.
The open select and NaN PRs barely change this module: perf(shader): skip masked-select families that have no candidate select #7491, perf(shader): leave out the both-zero select of f16 min and max #7516 and perf(shader): leave out the dead code pass after masked-select elimination #7522 by 0 words, perf(shader): fold masks, shifts and field extracts through bits they do not use #7673 by −1.7%, perf(shader): pick the f32 NaN result with one quiet and one fallback select #4287 by −1.5%.

What the NVIDIA compile time follows. These are agc_compute_pipeline_replay timings, with a unique nonce per run so the driver cache can't hit:

Module	`main`	`note_bda_write` marked `DontInline`
408k pipeline	41.6–75.9 s	15.4–34.8 s
408k pipeline with the four f32 constructs removed (−55% words)	72.4 s	23.9 s
345,497-word pipeline later in demo1 (796 `note_bda_write` call sites)	292.7 s	37.8 s

The ranges come from machine load. Removing more than half the words leaves the time unchanged. The time drops once note_bda_write, the atomic-CAS probe loop that every flat/global store calls, is no longer inlined at each store site; NVIDIA honours the hint. bda_anchor_range with the same flag makes no difference. On the AMD proprietary driver the change is smaller: 99.4 s to 88.2 s for AMD's 159k-word module.

Effect on the title (NVIDIA, repeated runs in one run folder):

With the flag, the cold run still stops, since the 408k build takes about 25 s against the title's 10 s wait. Each run caches one or two more pipelines. By run 12, demo1 plays for about 140 s at 40–49 fps, until a separate stop: guest memory is not readable at 0x400fa00058.
On main, the 345k pipeline was still compiling at the 240 s limit in each later run, so it was never cached.

The change is one line in DefineBdaNoteWrite, plus a ShaderMemory test that fails on main:
https://github.com/wachi35676/AnyPS5/tree/perf/shader-note-bda-write-dontinline (eb7d626cf)

Tests: with it, the agc|shader|spirv|recomp subset passes 783/783 on the RTX 5070 Ti. On the AMD iGPU, the 7 failures are the same as on main.
Why it isn't a PR:
- perf(shader): probe 32-bit BDA stores and share the write fallback #1282 dropped this flag because Mesa (ANV/RADV) inlines every function regardless. The flag can't help Mesa, but it doesn't change Mesa's output either.
- fix(shader): set a BDA-written page's bit inside the slot probe loop #3472 saw a device loss with the flag on NVIDIA 610.57 (Linux), with the probe loop as it was before fix(shader): set a BDA-written page's bit inside the slot probe loop #3472's fix. The current loop passes agc_driver_bda_device here on Windows, but I have no Linux NVIDIA machine to check it.
- I haven't measured runtime cost: frame rate looked normal, but I didn't compare it before and after.

A Linux NVIDIA run of agc_driver_bda_device and the flat_* tests on that branch would settle whether it's safe as a PR.

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

@wachi35676

@wachi35676 I tried your note_bda_write change on FSR4 Showcase. It doesn't change anything here, because these pipelines have no BDA stores.

AMD Radeon 860M (RDNA 3.5), driver 32.0.13058.8001, Windows 11, WinLibs GCC 15.2.0, Release. main f78675a, alone and with eb7d626 merged (clean merge). Ten runs per tree in one run folder, so each run caches the next slow pipeline. The executable was renamed per tree so AMD's driver cache starts empty. Builds over 500 ms from APS5_PROFILE_DRAW=1:

Pipeline (SPIR-V words)	`main`	with `eb7d626`
671,953	63.8 s	62.5 s
671,943	57.3 s	57.5 s
671,724	46.9 s	46.7 s
673,577	41.0 s	40.7 s
574,318	21.5 s	21.4 s
346,127	8.1 s	8.0 s
303,605	6.4 s	6.4 s

Both trees stop in the same places: run 1 at a vkQueueSubmit -4, runs 2 to 9 at fence=-4 stage=fsr4 after_ms=4521, and run 10 reaches chapter 2 and stops at vkQueueSubmit -4.

Why it makes no difference: I parsed the SPIR-V of the large modules in this run's shader_cache. Each one is a single function (main, one OpFunction, no OpFunctionCall) with no OpConvertUToPtr. So there is no note_bda_write to keep out of line. The cost of these builds comes from something else. Your change can still help titles that do BDA stores, like vkQuake in your measurements.

AI-assisted: yes (Claude Code)

@LeandroLP23

@LeandroLP23 on the chapter 2 question: on Linux with RADV it is not a new stop after #6270, and it goes away here once the caches are warm.

RX 7700 XT (RADV, Mesa), Fedora 44, GCC, Release, plain main b7a75819f. 11 runs in one run folder, so shader_cache and the pipeline cache carry over. The folder already held a cache from an older main.

Run	Result
1 (cold for this `main`)	`fence=-4 stage=fsr4 after_ms=4514` in chapter 0, exits after 11 s
2	chapter 2: `vkQueueSubmit(queue, 1, &s, fence) = -4`, the same line as yours
3	`fence=-4 stage=fsr4 after_ms=4528` in chapter 7
4 to 11	no stop; killed by my 120 s limit in chapter 9

shader_cache grew from 284 MiB to 435 MiB over runs 1 to 8 and then stayed the same. With the cache warm, a 300 s run went through all 12 chapters (0 FSR 4 on PlayStation 5 to 11 RCAS), looped back to chapter 0 and went round a second time with no error, as on 10-15.

So on this GPU the chapter 2 vkQueueSubmit -4 shows up only while that chapter still has pipelines to build, like the chapter 0 stop. Your runs keep stopping there after the caches stop growing, so on the Radeon 860M under Windows something else is going on, and I can't reproduce it here.

@YossiYad

@YossiYad thanks. My runs agree with yours. My stops at chapter 2 all happened while the caches were still growing, so I can't claim it persists with warm caches.

Same Radeon 860M, main f78675a, the run folder from my comment above (10 runs). I added 8 more runs, up to 300 s each:

Run	Builds over 500 ms	`shader_cache`	Furthest chapter	Stop
11	671,381 words, 39.2 s	79 MiB	2	`vkQueueSubmit` -4
12 to 15	one each, 264k to 574k words, 8.3 to 20.2 s	82 to 96 MiB	2	same
16	678,747 words, 79.6 s	104 MiB	2	same
17	three, 128k to 275k words	112 MiB	2	same
18	293,053 words, 5.6 s	114 MiB	6	same

Each run still builds at least one large pipeline before it stops, and it gets further once chapter 2's pipelines are cached. That matches your RADV runs: the chapter 2 stop is the same build-time stop as chapter 0. These builds take a lot longer here than on your RX 7700 XT, so the cache needs more runs to fill. I'm continuing in the same folder and will report whether it gets through all 12 chapters once nothing is left to build.

AI-assisted: yes (Claude Code)

Follow-up to my last comment: it does get through all 12 chapters on AMD Windows once every pipeline is in the cache.

Same work folder, same exe name and same build (f78675a) on a Radeon 860M (RDNA 3.5), driver 32.0.13058.8001, 300 s cap per run:

Runs	Pipelines built	Result
29–34	45 → 52, one large build per run (up to 79.6 s for a 678,747-word module)	stopped at chapter 9 with `vkQueueSubmit ... = -4`, cache 190 → 220 MiB
35–42	52, no new builds	chapters 0–11, then started again and reached chapter 10 of the second pass before the 300 s cap; no `FSR4_SHOWCASE_ERROR`, cache stable at 221 MiB

So on this machine the -4 (VK_ERROR_DEVICE_LOST) only shows up in runs that still compile a new large pipeline. With nothing left to build, eight runs in a row played the whole showcase without an error. It took 34 runs and about 221 MiB of AnyPS5 shader cache to get there (YossiYad's RADV cache reached 435 MiB).

RTX 5080 screenshots for boykopovar#6118

NVIDIA data for this issue: the RTX 5080 shows the same stop as the AMD runs above, and it also gets through all 12 chapters once every FSR4 pipeline is cached. It took 30 cache-filling runs and 244 MiB of shader_cache.

Host: Windows 11 Pro, Intel Core i9-14900K, 128 GB RAM, NVIDIA GeForce RTX 5080 (driver 32.0.16.1714), WinLibs GCC 15.2.0, Release, plain main 6af4e4d17. PPSA99011 01.000.010 was relinked once (relinker --windows --registry --trap-sdk-syscall-stubs) into a new run folder with a new executable name, and every run used that folder, so shader_cache, the pipeline cache and pipelines.journal carry over. APS5_PROFILE_DRAW=1, no controller, 300 s cap per run (the window was closed with WM_CLOSE at the cap). Times are seconds since process start.

Run	Builds over 100k words	Longest builds (words / time)	`shader_cache` after	Furthest chapter	Stop	Exit, run length
1 (cold)	1	405,148 / 2.8 s	4.2 MiB	before 0	`vkQueueSubmit(queue, 1, &s, fence) = -4`, during that build	0, 8 s
2	4	595,211 / 15.9 s, 127,464 / 1.3 s, 127,383 / 0.8 s	19.9 MiB	0	`fence=-4 stage=fsr4 after_ms=4565` at 5.8 s	0, 23 s
3	1	596,535 / 11.6 s	27.6 MiB	0	`after_ms=4572`	0, 14 s
4	2	346,963 / 5.2 s, 314,113 / 4.1 s	35.9 MiB	0	`after_ms=4565`	0, 12 s
5	2	519,308 / 12.3 s, 314,537 / 4.1 s	46.2 MiB	0	`after_ms=4563`	0, 19 s
6	1	824,538 / 27.0 s	56.1 MiB	0	`after_ms=4570`	0, 30 s
7	3	312,426 / 4.3 s, 324,055 / 3.6 s, 127,211 / 1.2 s	65.5 MiB	0	`after_ms=4567`	0, 12 s
8	3	595,050 / 16.1 s, 127,505 / 1.3 s, 127,365 / 1.2 s	78.2 MiB	2	`vkQueueSubmit(queue, 1, &s, fence) = -4` at 34.5 s	0, 52 s
9	1	594,967 / 15.1 s	85.9 MiB	2	same, 34.6 s	0, 48 s
10	1	347,208 / 9.0 s	90.2 MiB	2	same, 34.3 s	0, 40 s
11	2	314,035 / 6.8 s, 314,549 / 6.6 s	98.2 MiB	2	same, 34.2 s	0, 44 s
12	1	519,200 / 15.7 s	104.5 MiB	2	same, 34.2 s	0, 48 s
13	1	832,818 / 32.9 s	114.5 MiB	2	same, 34.3 s	0, 65 s
14	3	312,640 / 5.1 s, 325,335 / 3.4 s, 127,448 / 1.2 s	123.9 MiB	2	same, 34.5 s	0, 43 s
15	1	392,651 / 4.7 s	127.7 MiB	6	same, 85.0 s	0, 89 s
16	4	595,215 / 16.0 s, 132,590 / 1.2 s, 127,464 / 1.2 s	140.8 MiB	7	`fence=-4 stage=fsr4 after_ms=4669` at 101.7 s	0, 120 s
17	1	596,539 / 17.5 s	148.5 MiB	7	`after_ms=4677`	0, 116 s
18	1	346,967 / 9.5 s	152.8 MiB	7	`after_ms=4662`	0, 108 s
19	1	314,113 / 7.2 s	156.8 MiB	7	`after_ms=4666`	0, 106 s
20	1	314,537 / 7.1 s	160.7 MiB	7	`after_ms=4667`	0, 105 s
21	1	519,304 / 15.8 s	167.1 MiB	7	`after_ms=4679`	0, 115 s
22	1	824,538 / 27.5 s	177.0 MiB	7	`after_ms=4674`	0, 126 s
23	3	312,426 / 5.2 s, 296,321 / 3.5 s, 127,211 / 1.2 s	186.1 MiB	7	`after_ms=4666`	0, 109 s
24	3	595,054 / 16.8 s, 127,365 / 1.3 s, 127,505 / 1.2 s	197.4 MiB	9	`vkQueueSubmit(queue, 1, &s, fence) = -4` at 124.9 s	0, 144 s
25	1	594,971 / 16.1 s	205.1 MiB	9	same, 125.3 s	0, 140 s
26	1	347,208 / 8.5 s	209.4 MiB	9	same, 126.5 s	0, 132 s
27	2	314,035 / 6.8 s, 314,549 / 6.5 s	217.3 MiB	9	same, 125.5 s	0, 137 s
28	1	519,196 / 15.0 s	223.7 MiB	9	same, 126.1 s	0, 138 s
29	1	832,818 / 32.3 s	233.7 MiB	9	same, 126.4 s	0, 157 s
30	3	312,640 / 5.3 s, 325,339 / 3.6 s, 127,448 / 1.4 s	243.1 MiB	9	same, 126.2 s	0, 135 s
31 to 33	0	none	244.1 MiB	0 to 11, then 0 to 10 of a second pass	none, closed at the 300 s cap	0, 301 s

It is the same stop as on AMD. Every failing run from 2 to 30 stops while the queue worker is building FSR4 compute pipelines that aren't in the cache yet:

In 26 of the 29 runs, the build was still in progress when the title gave up. For example, run 13 started its 832,818-word build at 30.9 s, the title gave up at 34.3 s, and the build finished at 63.8 s.
In the other three (runs 2, 5 and 16), back-to-back builds used up the budget and the last one finished just before the stop: three 127k-133k-word builds of 0.7-1.3 s each (runs 2 and 16), or one 314k-word build of 4.1 s (run 5). The next large build started right after the stop.

None of the stops is the 10 s vkWaitForFences timeout:

The stage=fsr4 lines report after_ms 4563-4572 in chapter 0 and 4662-4679 in chapter 7, which is the compute-chain budget (3 s + 0.1 s × dispatches) that the AMD runs hit at 4514-4528.
The vkQueueSubmit ... = -4 stops come 4.50-4.52 s after FSR4_SHOWCASE_CHAPTER in all 14 runs that stopped in chapter 2 or 9, and 3.2 s after it in chapter 6, each with a build in progress. So they look like the same give-up, reported at the next submit instead of at a fence. I haven't checked that in ps5-vulkan.

AnyPS5 logs nothing for any of them: no what(), no VK_ERROR, no VUID-, no DEVICE_LOST line, and no driver message.

Why the cache grew every run. After FSR4_SHOWCASE_END result=FAIL the process stays up until the in-progress build ends: run 13 exited at 64.6 s, right after its 832,818-word build. The journal then holds that build, and the next run replays it at start-up in milliseconds ([pipeline-journal] loaded 60 pipelines ... 1 graphics and 59 compute built ... in 81 ms on the warm runs), so each run gets one or two pipelines further. The chapters that need new pipelines are 0, 2, 6, 7 and 9. Chapters 7 (1440p) and 9 (4K) rebuild the same set of modules as chapters 0 and 2, with word counts within a few words of the earlier ones but at new program addresses, so the cache has to fill four times. Runs 31 to 33 built nothing over 100k words, and the cache stayed at 244.1 MiB: 214 MiB of shader cache and a 31 MiB vk-pipelines-10de-2c02-*.bin. NVIDIA's own disk cache (%LOCALAPPDATA%\NVIDIA\DXCache) grew by 0.125 MiB (2 files) over runs 1 to 33, so all of the warm-up is in AnyPS5's caches.

Compile times against the AMD numbers above. The largest modules build about twice as fast here as on the Radeon 860M, and the small ones take about the same time:

SPIR-V words (RTX 5080)	RTX 5080	Radeon 860M, closest size from this thread
832,818 / 824,538	32.3-32.9 s / 27.0-27.5 s	794,551-796,524: 52.4-65.9 s; 671k-679k: 39-80 s
594,967-596,539	11.6-17.5 s	574,318: 21.5 s; 657,804: 24.0 s
519,196-519,308	12.3-15.8 s
346,963-392,651	4.7-9.5 s	346,127: 8.1 s; 391,143: 10.1 s
296,321-325,339	3.4-7.2 s	299,091-303,605: 6.4-8.3 s
127,211-132,590	0.65-1.4 s	131,187: 0.9 s

The 52 builds over 100k words took 443 s in total. The recompiled modules differ between the two GPUs, so the word counts don't match one to one. Even the fastest large build here is about 3.4 s, and the title's budget for a chain is about 4.5 s, so even on this GPU a cold first run can't save itself.

Frame time once cached, which differs from AMD. With everything cached the title is GPU-bound at about 3.4 FPS:

At 1080p the title's own FSR4_SHOWCASE_STATS reports fsr4_ms 276-320 against scene_ms 2-5, and 475 in the dynamic-resolution chapter.
The stats line covering the 4K chapters (8 and 9) reports fsr4_ms 436, and the overlay of chapter 9 (4K Ultra Performance) shows 977 ms, about 0.7 FPS.
APS5_PROFILE_GPU=1 puts the GPU at 282-290 ms busy per frame, almost all of it in the 12 FSR4 dispatches. The two heaviest are the 127,464- and 127,383-word programs (0x275520000, 0x275500000), at about 40 ms each per frame.

The chapter timer is wall-clock, so the tour still advances at its normal pace, about 12 s per chapter. For comparison, #6270 reported about 25 FPS on an RX 7700 XT with RADV, and 13-15 presents per 10 s on the Radeon 860M. So on NVIDIA the cached FSR4 pass is slow on the GPU, not only to compile; I haven't looked at why.

No 119.88 Hz: no run logs a 119.88 Hz mode or display no longer supports, and the window ran on the 60 Hz second display without a VideoOut error.

Window screenshots from the warm runs (the game window only):

Chapter 12 at 1080p, chapter 10 at 4K, the second pass at the 300 s cap

So on NVIDIA, too, the device loss shows up only in runs that still have a large FSR4 compute pipeline to build. With nothing left to build, three runs in a row played all 12 chapters and went round again with no FSR4_SHOWCASE_ERROR.

@dantdmdarealguy

@dantdmdarealguy on the cached frame time: on AMD's Windows driver it isn't faster, so this doesn't look NVIDIA-specific. These are the title's own FSR4_SHOWCASE_STATS lines from my nine fully cached runs (35-43, main f78675a, Radeon 860M, driver 32.0.13058.8001), output 1920x1080:

Stats line	`fsr4_ms`	`scene_ms`	`frame_ms`
frames=120, render 960x540, quality 3	665-681	11.3-13.3	694-714
frames=240, render 640x360, quality 4	867-880	24.5-27.1	928-941

That's about 1.1-1.4 FPS, with FSR4 taking 95 % of the frame, close to the 13-15 presents per 10 s in #6270. The 860M is a 16-CU integrated GPU, so 2-3 times the RTX 5080's 276-320 ms isn't surprising. On both AMD's and NVIDIA's Windows drivers the cached pass takes hundreds of milliseconds, against about 40 ms per frame for the RX 7700 XT on RADV. I didn't take a per-dispatch GPU profile.

AI-assisted: yes (Claude Code)

A retail title in this class, on NVIDIA: ASTRO BOT (PPSA21567, v01.018). Windows 11 26300, RTX 5070 Ti, driver 617.42, WinLibs GCC 15.2.0 r7, Release, main 2fade7e plus #10194.

Unlike the titles above, this one doesn't give up: it has no short wait, so the builds show as freezes during gameplay instead of a device loss. Builds over 1 s in one 8 minute run, from APS5_PROFILE_DRAW=1:

SPIR-V words	build time
467,991	7.3 s
439,179	7.0 s
423,365	6.5 s
390,745	5.9 s

They land on queue 0, so [packets] queue 0x0 charges the waiting packet: two windows with DISPATCH_INDIRECT x2 at 12,486 ms and 14,408 ms while [indirect] reported at most 15.8 ms inside the device call and driver phases queue 0 indirect showed recompile 39507.0 us per dispatch. An earlier run on the same build spent 96.7 s on 28 builds over 1 s; a warm run on the same tree spent 1.1 s on 32 pipeline creations in total, so the cache does its job once filled.

I wanted to try #5925 here, but it no longer merges onto main: 21 conflicting files, including VulkanDevice.cpp, PacketExecution.cpp and PipelineJournal.cpp, with #5875 alone or together. It would need a rebase before it can be measured against this title.

Not run: AMD or Linux, repeated runs to measure how many it takes to warm fully, per-build GPU profiles, and whether the freezes are visible once every pipeline is cached.

AI-assisted: yes

@dantdmdarealguy

Still reproduces on current main 3fea2a937b, on AMD and NVIDIA under Windows. The cause is the same: one FSR4 compute pipeline takes several seconds to build, and the title's queue wait gives up first.

Setup: WinLibs GCC 15.2.0, Release, PPSA99011 01.000.010 relinked with the catalog's --trap-sdk-syscall-stubs, APS5_PROFILE_DRAW=1, 300 s cap per run. Each series starts in a new folder, so the first run has empty caches and later runs reuse them.

Host	Run	Furthest point	Stop	Largest build in the run
Radeon 860M, AMD 32.0.13058.8001	1 (cold)	before chapter 0	`vkQueueSubmit(...) = -4` at ~9 s	317,249 words, 7,064 ms
	2	chapter 0	`fence=-4 stage=fsr4 after_ms=4522`	645,499 words, 20,367 ms (the 317k one now loads in 4 ms)
	3	chapter 0	`fence=-4 stage=fsr4 after_ms=4523`	647,444 words, 15,081 ms (the 645k one now loads in 9 ms)
RTX 5060 Ti, NVIDIA 621.01, i5-10600K	1 (cold)	before chapter 0	`vkQueueSubmit(...) = -4` at 9.3 s	432,229 words, 5,773 ms

A second cold run on the 860M gave the same stop, with the 317k pipeline built in 6,429 ms.

Each run caches one more large pipeline and then stops on the next one. This matches the 30 cache-filling runs @dantdmdarealguy needed on the RTX 5080. The same program (0x275480000) is 317,249 words on AMD and 432,229 words on NVIDIA.

So the issue is not fixed on main. #5925 (building a submission's pipelines ahead on a compile pool), whose thread has FSR4 measurements, is still open.

AI-assisted: yes (Claude Code)

Navigation Menu

Repository navigation

AGC: PS5 FSR4 Showcase (PPSA99011) gives up in its first FSR4 pass while the queue worker builds 130k-800k-word compute pipelines (up to 66 s each on AMD) #6118

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

AGC: PS5 FSR4 Showcase (PPSA99011) gives up in its first FSR4 pass while the queue worker builds 130k-800k-word compute pipelines (up to 66 s each on AMD) #6118

Description

Activity

LeandroLP23 commented on Oct 14, 2026

MarcZX10 commented on Oct 15, 2026

LeandroLP23 commented on Oct 15, 2026

LeandroLP23 commented on Oct 15, 2026

babyhuey commented on Oct 18, 2026

LeandroLP23 commented on Oct 18, 2026

wachi35676 commented on Oct 19, 2026

wachi35676 commented on Oct 19, 2026

LeandroLP23 commented on Oct 19, 2026

YossiYad commented on Oct 19, 2026

LeandroLP23 commented on Oct 19, 2026

LeandroLP23 commented on Oct 19, 2026

dantdmdarealguy commented on Oct 19, 2026

LeandroLP23 commented on Oct 19, 2026

cadenasynyster commented on Oct 24, 2026

LeandroLP23 commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions