Mandragora: Whispers of the Witch Tree (PPSA06960)

[klosixgaming-arch]

Existing thread

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

Title

Mandragora: Whispers of the Witch Tree (PPSA06960)

Content version tested

01.006.002

AnyPS5 commit

main at 5d9dcc4 (merge of #6372), built together with #5651 and #6343 rebased on it; this title does not need either

System tested

Windows 11, WinLibs GCC 15.2.0 (x86_64-posix-seh, ucrt, r7), RTX 5090 (NVIDIA 617.42), AMD Ryzen 9 9950X3D

Furthest point

In game

What is shown

Intro and logo screens, the privacy policy screen, the menus, new game loading, character select and the first gameplay scene all render and take controller input (Xbox pad). The intro screens and some cutscenes run at 60 fps. The first gameplay scene runs at about 5 fps (170 to 200 ms per frame), and the title freezes for up to about 20 seconds when it shows a new screen for the first time, because shaders are compiled then (about 3,800 shaders and 6 GB of shader cache after the first pass through the intro; hundreds more in the first gameplay scene). I did not check audio.

Current blocker

No stop and no crash: the frame rate in gameplay. No issue or pull request tracks it yet, and the title needs no open pull requests or local changes.

Profile of the first gameplay scene (APS5_TRACE_SUMMARY_EVERY=10, APS5_PROFILE_GPU=1), frame p50 about 172 ms, per frame:

• Driver.Packet.memory_wait 170 to 230 ms, the time a queue spends in WAIT_REG_MEM packets (opcode 0x3c) waiting for another queue
• Driver.Draw about 105 ms
• Draw.shader_compile_and_link about 70 ms
• the GPU itself is not the limit

Queue 0 (queue worker 0x0) is 99% busy; the compute queue (queue worker 0x20) is 75 to 125% busy. The intro and cutscene intervals show about 16.7 ms per frame with memory_wait under 80 ms.

Four WAIT_REG_MEM timeouts were logged while loading, for example:

[gpu] queue 0x20 WAIT_REG_MEM at 0x1020ea4760 timed out after 1000ms (function 3 ref 0x1 mask 0xffffffff value 0x20eba6a0)
[gpu]   preceding packet WAIT_REG_MEM 00000013 20ea4760 00000010 00000001 ffffffff 00000019

The value found in memory is not 1 and looks like the low half of an address, so the wait may be on memory that nothing writes with the expected value. This is not confirmed.

Also logged: texture ... has mixed DCC keys ...; its texels are read as stored (10 times) and guest memory changed while GPU results were pending; keeping the CPU's blocks.

How it was run

The dump (an Unreal Engine 4 title) has a 175 MB eboot.bin, 25 plugins in prx/ and 5 modules in sce_module/ (libc, libSceFontGsm, libSceJobManager, libSceNpCppWebApi, libScePfs), all SELF containers. tools/unwrap_self.py on main unpacks all of them without changes. The unpacked system modules have to be in sce_module/ under the --sce-module-path directory: with them next to the eboot, the relinker did not convert libSceNpCppWebApi.prx and the title stopped with dependency module not found: libs\libSceNpCppWebApi.prx. prx/ is searched by default, and --module-dir prx fails with Duplicate guest module directory.

relinker --windows --windows-diagnostics --trace-imports --registry --sce-module-path <unpacked dir> <unpacked dir>/eboot.bin app.exe

app0 holds the dump's man, engine and sce_sys (junctions), ue4commandline.txt and the original eboot.bin; the converted plugins are written to app0/prx. Environment: ANYPS5_GPU=5090, VK_LOADER_DRIVERS_DISABLE=*dzn*.

With APS5_TRACE_CALLS=all set, the first launch was killed by the engine's own check after 120 seconds (GameThread timed out waiting for RenderThread after 120.00 secs) while thousands of shaders were compiled and about 100 million calls were traced. Without it the title ran on. Setting APS5_PREBUILD_THREADS=8 and APS5_PIPELINED_DRAWS=64 changed the gameplay frame rate from about 5 to about 5.5 fps.

AI-assisted: yes. Written with AI assistance and reviewed by me.

[klosixgaming-arch]

Profile of the gameplay frame rate (first gameplay scene, about 5 fps, 172 ms per frame), same build as above, APS5_PROFILE_DRAW=1, APS5_TRACE_SUMMARY_EVERY=10, APS5_SAMPLE_THREADS.

Where the time goes. The title submits about 1,000 draws per frame (46,000 to 55,000 draw packets per 10 s). The queue 0 worker costs 106 to 127 µs per draw packet, of which 54 to 68 µs is waiting for the GPU mutex. The pipelined committer takes 98 to 106 µs per commit and holds the GPU mutex at the draw site for 8,088 of every 10,000 ms ([lock] line, 54,599 holds, longest 17.4 ms). So the draw path is serial, and about 1,000 draws x 106 to 170 µs is the frame time. The compute queue (queue worker 0x20) is 75 to 125% busy but only waits for the other queue; its 1 s WAIT_REG_MEM timeouts are not the limit (the memory_wait phase is that worker's wait time). The GPU is not the limit: gputime shows 240 to 480 ms of GPU time per 10 s.

What the committer thread does (sampler, difference between two snapshots in gameplay, about 970 active samples): AllKeysEqual (DCC key scan) 36%, memcmp under GuestMemory::EqualsCommittedUnsynced 34%, DepthSurfaceView 24%. [dcc] reports 12.3 million scans and 971 GiB scanned after about 20 minutes; key proofs were 0 proved, 4,188,227 scanned, all unstable. [guestmem] reports compare 351,839 calls, 782 GiB, 27.3 s.

Revalidation. [rescache] revalidate: 1,547,520 calls, 69,951 ms in total, fast path 326,306, full walks 1,221,072. The reason for 1,200,507 of the fast-path failures is collect. A local diagnostic build (not for a PR) that logged why GuestMemory::CollectWrites returned 0 showed the same cause in all 55 logged cases: tracker.coverage.Covers() was false, so the range is outside the write watch (it was not a host region and no walk failed). Those ranges are small (0x1000 to 0xb9000 bytes, for example 0x2018ef0000 + 0x10000). I did not find which callers excluded them; GuestMemory::Unwatch and WriteWatchCoverage::Exclude are the places that do. In a second run, 173,478 of 233,142 revalidations (74%) were full walks, 18,997 ms in total.

What might help (not tried): a cheap change test for the ranges outside the write watch, so the fast path applies to them, and preparing draws on more than one thread. Setting APS5_PREBUILD_THREADS=8 and APS5_PIPELINED_DRAWS=64 changed the frame rate by only about 10% in an uncontrolled comparison (the second run also had a warm shader cache).

AI-assisted: yes. Written with AI assistance and reviewed by me.