Blue Prince (PPSA25009)

[JJenkx]

Existing thread

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

Title

Blue Prince (PPSA25009)

Content version tested

02.001.000

AnyPS5 commit

main 2abfb1beb4 with #8847.

System tested

Linux 7.2.9 (Arch), Ryzen 9 7950X, Radeon RX 6650 XT, RADV Mesa 26.2.4, GCC, Release.

Furthest point

Menu

What is shown

The studio logo, the credits text and the 3D desk scene, with no stop in 180 s and 160 s runs. Input and progress past the desk scene were not checked.

Frame rate on the desk scene with a warm shader cache: APS5_TRACE_SECONDS=120:30, APS5_TRACE_EVENTS=4194304, dropped: no:

• 248 presents in 30 s, frame p50 119.7 ms / p90 133.5 ms, GPU busy 58.1 ms per present.
• The queue worker is busy 78 ms per frame. 51 ms of that is Driver.Draw.shader_compile_and_link: about 1655 calls per present at about 31 µs each, i.e. once per draw, with Shader.DrawStage at about 677 per present. With a warm cache this is per-draw shader resolution, not compilation, the same pattern as the Castlevania and Pumpkin Jack reports in Castlevania: Belmont's Curse (PPSA35399) #5832 and Pumpkin Jack (PPSA03446) #8421.

Current blocker

None (no stop). Per-draw shader resolution limits the frame rate on this scene.

How it was run

relinker --registry --rpath <build>/core/libs/libs --module-dir Media/Modules --module-dir Media/Plugins eboot.elf app.elf

Protocol note (added 2026-10-23): the frame times above were captured with the game's stdout and stderr redirected to a file by my harness. The Performance report form asks not to redirect the log, so they are diagnostic, not form-compliant captures.

AI-assisted testing and report: yes, Claude Code.

[JJenkx]

Follow-up on the per-draw shader_compile_and_link cost above. On this scene, the draw cache is too small for the working set.

Pins: clean Release 7ab4b2e561; Linux 7.2.9, Ryzen 9 7950X, Radeon RX 6650 XT, RADV Mesa 26.2.4. All runs use the same scripted input (Cross every 15 s from 25 s to 100 s), cleared saves and a shader cache seeded by a discarded warm-up run. Traces use APS5_TRACE_SECONDS=120:25 (seconds 120–145, in the 3D scene) and APS5_TRACE_EVENTS=4194304; every trace below reports dropped: no. APS5_TRACE_DRAW_CACHE=1 prints the cache's 10 s counters. The two sides differ only in APS5_DRAW_CACHE_ENTRIES.

Default 4096 entries. On the menus the draw cache hits 84–90 %. In the 3D scene it stays at 4096 entries:

• about 160,000 evictions per 10 s;
• a hit rate of 1–7 %;
• about 500,000 stage compiles per 10 s through the data-only path.

55–65 % of lookups find no entry because it was evicted. Another 75,000–107,000 per 10 s find none because the admission filter, which drawCacheEntries() also sizes, forgot the key before its second sighting.

APS5_DRAW_CACHE_ENTRIES=32768: hit rate 74–87 %, and stage compiles drop to 84,000–173,000 per 10 s.

run	entries	frame p50	p90	GPU busy per present
bd2	4096	118.5 ms	133.2 ms	57.9 ms
be1	32768	99.9 ms	124.0 ms	56.3 ms
be2	32768	99.3 ms	125.2 ms	56.4 ms
bd3	4096	168.1 ms	190.7 ms	60.6 ms
be3	32768	132.0 ms	171.3 ms	59.6 ms

The machine's load average was about 9 during bd3/be3, so compare within each pair: about 16 % and 21 % lower frame p50. The rest of the frame is GPU-bound (about 57–60 ms of GPU work per present), so frame time doesn't track the hit rate. A third default run (bd1) stopped at 148 s on base with AGC graphics: storage texture has no committed guest pages. That's an intermittent stop, unrelated to the cache size.

Cost: with APS5_PROFILE_DRAW=1, the cache holds 4096 entries with 8192 variants in about 8 MiB at the default, and 32768 entries with about 67,000 variants in about 69 MiB. Even 32768 fills on this scene. Peak RSS goes from 5.53 to 5.86–5.88 GiB in both pairs, so most of the extra is per-entry state outside the variant count.

I'm not proposing a new default from one title: the RSS cost applies to every title that fills the cache, and #9129 (byte bound), #5404 (bypass at low hit rates), #5609 and #6539 (reuse across moved bases and value-only user words) all change this cache. For this title, APS5_DRAW_CACHE_ENTRIES=32768 is the existing override.

Traces with SHA256SUMS, summary lines, digests, draw-cache counters, the bd1 stop and RSS samples: 20261021-blueprince-drawcache-PPSA25009.tar.gz (sha256 6626f1fb715b1915b7f37d0d8cad928890d965c204d8aad9c6940cf6bb904c2a).

Protocol note (added 2026-10-23): these captures ran with the game's stdout and stderr redirected to a file by my harness, on both sides of each comparison. The Performance report form asks not to redirect the log, so the numbers are a diagnostic comparison under identical conditions, not form-compliant captures.

AI-assisted testing and report: yes, Claude Code.

[JJenkx]

Where the remaining GPU time goes, with APS5_DRAW_CACHE_ENTRIES=32768 on the same base 7ab4b2e561. The guest renders 1920x1080.

APS5_PROFILE_GPU=1: per present, the draw class is about 153 draws and 54–55 ms. Everything else is small: fill 0.9 ms, storage upload 0.3 ms, the rest under 0.3 ms, and about 2.4 ms untimed. That's about 74 recorder batches per present. Over seconds 120–145 of the trace (31,617 draws), per-draw GPU time is p50 180 µs, p90 902 µs, p99 2.2 ms. The top 1 % of draws is only 7 % of draw time, so the cost is spread over most draws, not a few.

RenderDoc capture at 130 s, with per-event EventGPUDuration on replay. Totals cover the whole capture, so they're relative weights, not one frame's time:

• 1920x1080 R16G16B16A16_FLOAT 4x MSAA colour: 161 ms across 1328 draws
• depth only: 92 ms across 2076 draws
• 512x512 R16G16B16A16_FLOAT 4x MSAA: 85 ms across 958 draws
• everything else: about 8 ms

Several of the most expensive single draws are 6-index full-screen quads, about 1 ms each, on the 4x MSAA 1080p target.

Not per-sample shading. Those quads and the heavy geometry draws all have sampleShadingEnable off (minSampleShading 0). That matches the driver, which sets it only from the guest's PA_SC_MODE_CNTL_1 iterate-samples bit (State.cpp:1235). A full write of a 1080p RGBA16F 4x target is about 66 MB, so about 1 ms per full-screen pass on this GPU is consistent with bandwidth. These passes look bandwidth-bound in the title's own render configuration.

One thing the capture shows but doesn't measure: every fragment shader I checked interpolates its inputs itself, through VK_KHR_fragment_shader_barycentric (gl_BaryCoordKHR plus per-vertex [0..2] inputs), not through fixed-function interpolation. Whether that costs anything on RADV would need an A/B I haven't done.

Replay outputs, [gputime] lines and the two scripts: 20261021-blueprince-gputime-PPSA25009.tar.gz (sha256 03f2ce800cbb0a277173143c437941019c0ef6359a057ecaeb6a452fd0bf52e9). The 442 MB capture isn't attached.

Protocol note (added 2026-10-23): these captures ran with the game's stdout and stderr redirected to a file by my harness, on both sides of each comparison. The Performance report form asks not to redirect the log, so the numbers are a diagnostic comparison under identical conditions, not form-compliant captures.

AI-assisted testing and report: yes, Claude Code.