Thymesia (PPSA05213)

[JJenkx]

Existing thread

• I searched this category for PPSA05213 and "Thymesia"; no thread exists.

Title

Thymesia (PPSA05213)

Content version tested

The extraction's eboot.bin. The dump has no PlayGo metadata files.

AnyPS5 commit

main 474030e584, with no extra PRs.

System tested

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

Furthest point

In-game: the HUD and the first tutorial.

What is shown

300 s, Cross every 12 s from 30 s, APS5_PLAYGO_UNLISTED_CHUNKS=installed.

• The intro story cut-scene with narration subtitles ("The various kingdoms tried to fend off the sickness…").
• In-game: the health and stamina bars, the currency counter and the "Basic Controls" tutorial, which closes with Circle; my script pressed only Cross.
• The run lasted until the scheduled close at 294 s, exit 0, with no driver failure.

Current blocker

Speed: about 55 FPS on the first screens, then 3 to 7 FPS from the cut-scene on. Not investigated yet.

How it was run

relinker --registry --rpath <build>/core/libs/libs eboot.elf app.elf
APS5_PLAYGO_UNLISTED_CHUNKS=installed ./app.elf

AI-assisted testing and report: yes.

[JJenkx]

Where the frame time goes in the first area, on the same main 474030e584. Two runs: one with APS5_PROFILE_GPU=1 APS5_PROFILE_GPU_DRAWS=1 APS5_TRACE_SECONDS=200:20, and one with APS5_TRACE_DRAW_CACHE=1. The renderer is at 3840x2160.

Frame: p50 139 ms, p90 177 ms. The GPU is busy about 79 ms per present, so the CPU is the larger part.

GPU per present:

Class	Count	GPU time	Data
draw	206	58.5 ms	—
copy	15	3.2 ms	80 MiB
dcc-clear	14	1.8 ms	522 MiB

There are 7,590 host-import fallbacks to copies over the run.

CPU per frame:

Phase	Time
Driver.Packet	285 ms
Driver.Packet.memory_wait	136 ms
Driver.Draw	99 ms
Driver.Draw.shader_compile_and_link	63 ms
Shader.DrawStage	54 ms

No new draw variants appear after about 100 s, so the 63 ms is not shader compilation. It is the per-draw stage materialization that phase covers.

Draw cache, per 10 s: 246,299 lookups with 0 hits (0.0%). Every miss is "user words/pointers only": the user data changes on every draw, and register-key misses are mostly user data (246,299). The data-only path reuses 127,362 stages and compiles 364,186. #12478's bypass would not trigger here, because data-only hits count as useful lookups.

So in this UE4 title most of the CPU time is re-materializing stages for draws whose only difference is their per-draw user-data pointers. Spirit of the North, Insomnis and Asterigos also run at about 10 to 13 FPS. I have not profiled them, so I am not claiming they share the cause.

AI-assisted analysis: yes.

[JJenkx]

Draw-cache check for Thymesia (PPSA05213) against #12478 ("bypass the draw cache while its hit rate is under 5%", head da441e01cc), merged onto main 381891927c. Linux 7.2.11, RX 6650 XT, RADV Mesa 26.2.6, Release.

Method: four 260 s runs in the order main, #12478, main, #12478, each launched separately. All use the same input (Cross every 12 s from 30 s), APS5_PLAYGO_UNLISTED_CHUNKS=installed and APS5_TRACE_DRAW_CACHE=1.

Arm	Run 1 median FPS after 150 s	Run 2 median FPS after 150 s
main	4.95	7.35
main + #12478	4.33	7.28

The two orders differ far more than the arms do, and #12478 shows no gain here.

Draw-cache trace, both arms, per 10 s: about 145,000 to 158,000 lookups with a 0.0% hit rate. Every miss comes only from changed user words or pointers, and 145,000 to 157,000 of the lookups are data-only hits: 75,000 to 82,000 stages reused and 215,000 to 232,000 compiled. With #12478 the lookups continue at the same rate, so the bypass did not take effect on this scene. These figures describe the cache, not why the bypass stayed off.

All four runs exit 0 at the scheduled close.

AI-assisted analysis: yes.

[EagleBearerYS]

Thanks for checking #12478 on Thymesia (PPSA05213). The bypass staying off there is what it should do on this scene.

It starts only after two windows of 2,048 lookups in a row where under 5% of lookups are useful. A lookup counts as useful in three cases:

• the whole draw hits;
• a cached draw of the same shape is found for one of its stages;
• its draw key was seen before.

The second case is the trace's data-only hit. In your trace, 145,000 to 157,000 of the 145,000 to 158,000 lookups per 10 s are data-only hits, so every window is far above 5%. Those lookups reuse 75,000 to 82,000 stages per 10 s from the cache. A bypass would skip the cache and give up that reuse.

So the same frame rate in both arms is the expected result here. The 0.0% is the whole-draw hit rate, which the bypass doesn't go by alone.