Trek To Yomi (PPSA02629)

[JJenkx]

Existing thread

• I searched this category for PPSA02629 and "Trek To Yomi"; no thread exists.

Title

Trek To Yomi (PPSA02629)

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

Opening cut-scene, with APS5_PLAYGO_UNLISTED_CHUNKS=absent.

What is shown

APS5_PLAYGO_UNLISTED_CHUNKS	Result
installed	Before a window, UE4 reports Ran out of memory allocating 5565054976 bytes with alignment 65536 and the process ends with SIGSEGV (exit 139) at 20 s. It is the same size and pattern as Unbound (#10204) and The Pathless (#9606).
absent	Startup passes, and the opening cut-scene plays with "Hold △ to skip". The run lasted until the scheduled close at 294 s, exit 0, with no driver failure.

Current blocker

Speed: about 1.4 FPS once the cut-scene starts, after about 60 FPS on the first screens. The image is also blotchy; the cut-scene is meant to be black and white. The engine logs no further allocation failure in 294 s.

How it was run

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

Cross every 12 s from 30 s. AI-assisted testing and report: yes.

[JJenkx]

Where the cut-scene's time goes. Same build and setup as above, with APS5_PROFILE_GPU=1 APS5_PROFILE_GPU_DRAWS=1 APS5_TRACE_SECONDS=140:20, and a trace window inside the cut-scene.

Per frame:

• Frame time: p50 436 ms, p99 559 ms, so about 2.3 FPS while profiling.
• GPU busy: about 118 ms per present. The rest is CPU.
• CPU phases: Driver.Packet 836 ms, Driver.Packet.memory_wait 384 ms, Resources.Complete 319 ms, Graphics.Draw 285 ms. Both queue workers are about 99% busy.

GPU by class, per present:

Class	Count	GPU time	Data
storage-upload	79	69.6 ms	1,140 MiB
draw	175	58.5 ms	—
storage-writeback	—	about 22 ms	—
copy	—	6.4 ms	210 MiB

Memory:

• Host imports: 7,089 imports failed at vkAllocateMemory (-1000072003, invalid external handle) and fell back to copies. 6,401 of them were requested by build. At shutdown 13,467 imports were live (6.3 GB), with 0 refused.
• Storage image cache: the cache budget fell from 2,632 MiB to between 1,240 and 1,572 MiB while 1.2 to 2.4 GB of storage images were cached, against a device-local budget of about 5.3 GB of which 4.5 to 4.8 GB was in use.

So the cut-scene re-uploads more than a gigabyte of storage images every frame, and the CPU waits on that work. Both the storage cache's eviction under this budget and the failed imports feeding it look like candidates. I haven't split their shares.

AI-assisted analysis: yes.

[JJenkx]

A check of whether the failed host imports cause the storage churn above. Same setup and window, with #4449 (scattered direct memory imports, head 2f225f0ff2) merged onto main 0836dfdf4f locally. Its CMakeLists.txt conflict touched only test targets; I resolved it on main's layout and re-added its test source.

Build	Failed host imports	storage-upload per present	GPU busy per present	Frame p50
main 474030e584 (above)	7,089	79, 1,141 MiB, 70 ms	118 ms	436 ms
+ #4449	1	112, 1,654 MiB, 146 ms	302 ms	428 ms

With #4449 almost every import succeeds, but the storage-image re-uploads remain and are larger, and the cut-scene frame time stays about 0.43 s.

So the churn is not driven by the import failures. It comes from the storage image cache: entries evicted and uploaded again every frame, with the cache budget at about 1.2 to 1.6 GB against the 1.2 to 2.4 GB in use. These are single profiled runs, not a matched A/B, so this is no performance claim for #4449 either way.

AI-assisted analysis: yes.

[JJenkx]

A correction to my two comments above. "Storage-upload" was the wrong reading of what the cut-scene re-sends every frame. With APS5_PROFILE_DRAW=1 on the same main, the [storage] breakdown per 10 s is:

Path	Count	Data
clear, reason keys	323 to 336	13.4 to 13.9 GB
direct	34 to 63	87 to 170 MiB
cpu	0	0
cache eviction write-backs	25 to 40	56 to 119 MiB
slab evictions	9 to 29	—

So the 1.1 GB per frame are DCC-key clears: the title clearing its targets every frame, which the driver performs on the GPU. They are not cache evictions and not re-uploads of guest data. The cost of those clears is what looks wrong. A likely reason is that these storage images were placed outside device-local memory under the 8 GB card's budget at 3840x2160. I have not confirmed that placement for these images.

AI-assisted analysis: yes.