Graven (PPSA09614)

[JJenkx]

Existing thread

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

Title

Graven (PPSA09614)

Content version tested

01.000.001

AnyPS5 commit

Import audit only: first on main d6eafa5, then on main 7e2ba73 with #9628 merged locally (2026-10-22). The title has not been launched.

System tested

Windows 11 Enterprise 10.0.22621, WinLibs GCC 15.2.0 r7 (UCRT), Ryzen 9 5950X, RX 6700 XT. Not launched on it.

Furthest point

Not launched yet. The executable and modules have been unwrapped and converted with relinker --registry into a local runtime, and the import audit run. With #9628 the audit reports no absent import (exit 0).

What is shown

Nothing yet: not launched.

Current blocker

On main the loader can't start the title. It imports sce::Json::Array::pop_front (pPs3qZTZQvQ, libSceJson2) from one call site, and no built library exports it. tools/import_audit.py lists it as the only absent import (exit 1). #9628 implements it, and with #9628 the audit reports no absent import.

Beyond that, on main 7e2ba73 with #9628 merged locally, 23 functions the title or its modules import (36 import entries) are exported but throw when called. The sceAjm* ones in the first audit are implemented on main since. Whether the title reaches any of them is unknown until it runs. Open pull requests that name each one (found by search; not checked to implement it fully):

• __tls_get_addr (from libSceJobManager.prx and libc.prx): feat(libkernel): implement __tls_get_addr #9059
• sceAgcAcbPushMarkerSpan, sceAgcAcbSetMarkerSpan, sceAgcDcbPushMarkerSpan, sceAgcDcbSetMarkerSpan: feat(agc): push and set debug markers from a text span #8924
• sceAgcAcquireMemSetEngine: feat(libSceAgc): implement sceAgcAcquireMemSetEngine #1060, feat(agc): push and set debug markers from a text span #8924
• sceAgcAcbSetWorkloadComplete, sceAgcAcbSetWorkloadStreamInactive, sceAgcAcbSetWorkloadsActive, sceAgcDcbSetWorkloadStreamInactive: docs(agc): record the console's workload packets #8302
• sceAgcDcbBeginOcclusionQueryGetSize, sceAgcDcbEndOcclusionQueryGetSize, sceAgcDriverRequestCaptureStart, sceAgcDriverRequestCaptureStop, sceAgcDriverTriggerCapture: fix(agc): return the console results of the capture, shader instrumentation and occlusion query size calls #8296
• sceAgcUpdateInterpolantMapping_0100: fix(libSceAgc): match interpolant mapping variants to firmware #8402
• sceCoredumpSetUserDataType: fix(libkernel): give sceCoredumpSetUserDataType its signature and result #8906
• sceGameLiveStreamingGetProgramInfo: feat(libSceGameLiveStreaming): answer sceGameLiveStreamingGetProgramInfo with an empty program #9031, feat(libSceGameLiveStreaming): implement sceGameLiveStreamingEnableLiveStreaming #9319, feat(libSceGameLiveStreaming): answer offline setting and feedback calls locally #9524
• sceSystemServiceParamGetInt: feat(libSceSystemService): handle parameter 100 in sceSystemServiceParamGetInt #9591, fix(libs): values measured on a PS5 (firmware 13.40) from inside retail games #7965
• sceVoiceQoSGetLocalEndpointAttribute: feat(libSceVoiceQoS): keep connection attributes and read stored attributes back #8656
• sceWebBrowserDialogResetCookie: feat(libSceWebBrowserDialog): check the cookie calls as the console does #8904
• sceFontGraphicsDrawupFillTextureImageObject, sceFontGraphicsDrawupFillTexturePatternObject (from libSceFontGsm.prx): no open pull request found

These become needs only if a run stops on one; until then they are not listed as required.

Open pull requests this title needs

• feat(libSceJson2): implement sce::Json::Array::pop_front #9628 sce::Json::Array::pop_front (the absent import)

How it was run

Not run. The audit used the dump's eboot.bin and sce_module/ (read only): tools/unwrap_self.py, relinker --registry --windows with the modules beside it, then tools/import_audit.py on the registries with the unwrapped modules as --modules. #9650 proposes that as one tool. A first launch on Windows is waiting for a free slot on the shared launch queue.

[JJenkx]

Static notes before the first run (no launch yet; the run will go through the shared launch queue):

• Engine: Unreal Engine 4. ue4commandline.txt is ../../../Praest/Praest.uproject, and the content is one praest-ps5.pak.
• Movies: all nine praest/content/movies/*.mp4 files (the 3dfx splash, logos, intro, loading and hub cutscenes) are H.264 video with AAC audio. I read each file's stsd sample entries. So the Videodec2 VP9 stop seen in other UE4 titles (picture info is only implemented for H.264) should not apply. graven_loading.mp4 and graven_logos.mp4 play early.
• Imports: rechecked against main 8b3a6ba + feat(libSceJson2): implement sce::Json::Array::pop_front #9628: 0 absent, 36 stub. The list of throwing functions in the opening post is unchanged.

AI-assisted (Claude Code).

[JJenkx]

First run on Windows, through the shared launch queue.

• Build: main 8b3a6ba + feat(libSceJson2): implement sce::Json::Array::pop_front #9628 (sce::Json::Array::pop_front, the title's only absent import), Release, WinLibs GCC 15.2.0 UCRT.
• System: Windows 11 Enterprise 10.0.22621, Ryzen 9 5950X, Radeon RX 6700 XT (AMD proprietary driver).
• Content: 01.000.001, cold shader cache, no save data. 300 s cap, no input.

Result. No stop, crash or unimplemented call in 319 s. Kernel and module start, the Vulkan device comes up, and the game threads start.

• It had not yet opened video output when the cap ended it.
• Nearly the whole run was first-time shader translation. The disk cache reports 0 hits, 1,085 misses and 1,093 writes, 653 MiB in the first 20 s window and 1.9 GB on disk afterwards.
• The failed opens in the log are ordinary UE4 probes for optional files: keyvaluestore.ini, saved/paks, editor settings, crash-report config.
• There are no screenshots: desktop capture failed on this machine during the run.

A second run with the cache warm, a 600 s cap and frame-time summaries every 30 s is queued, and I'll post its result here.

[JJenkx]

Runs 2 and 3 on the same build and machine as the first, with the shader cache warm from run 1.

• Run 2: the title creates its presentation surface and starts drawing, then stops by design about 120 s in. The dump has no playgo-chunk.dat or playgo-scenario.json, so scePlayGo cannot tell whether chunk 1 is installed:

  what():  scePlayGo: sce_sys/playgo-chunk.dat and sce_sys/playgo-scenario.json are missing, so chunk ID 1 cannot be checked; set APS5_PLAYGO_UNLISTED_CHUNKS=installed or =absent to answer for this title
  

• Run 3: with APS5_PLAYGO_UNLISTED_CHUNKS=installed it boots to the "press X to continue" screen and stays there for the whole 600 s cap. No stop, crash or unimplemented call. The run had no controller input, which is why it never got past that screen.

Interval (from APS5_TRACE_SUMMARY_EVERY=30)	Presents	Frame p50	Frame p99
0–30 s	1,453	16.69 ms	40.8 ms
30–60 s	1,764	16.69 ms	35.1 ms
60–90 s	1,781	16.69 ms	28.8 ms
480–570 s	1,799 each	16.69 ms	16.9 ms

So the title screen runs at a steady 60 fps on the RX 6700 XT, with no performance claim beyond that screen. A run that presses X through the pad input file (APS5_PAD_INPUT_FILE with tools/pad_input.py) is queued, and I'll post where it gets to.

[JJenkx]

Windows update: Graven now reaches the in-game intro.

Setup: RX 6700 XT (AMD 26.10.1), same runtime as my last post, APS5_PLAYGO_UNLISTED_CHUNKS=installed, pad input scripted through APS5_PAD_INPUT_FILE + tools/pad_input.py.

What changed: the "Welcome to GRAVEN" dialog wasn't dropping input. Its focus starts on the "Skip the intro sequence" checkbox, so X only toggled that. Pressing down first moves focus to "Ok", and then X goes through.

Progress in a 600 s run:

1. Title, menu and New Campaign at 48–60 fps, as before.
2. By 90 s: "Select a Difficulty", ~50 fps.
3. By 240 s: the campaign loading screen.
4. Loading took one 180 s frame. Presentation stalled during it; queue 0 and queue 0x20 logged WAIT_REG_MEM ... timed out after 1000ms warnings, and every one of them later resolved.
5. From ~420 s: the in-game intro (boat scene, credits, subtitles), at about 5–10 fps (frame p50 ~180 ms). Both queue workers are near 100% busy, and Vulkan.GraphicsPipeline.create dominates the phases.

Rendering is badly wrong in game:

• Almost the whole image is a washed-out pale cyan/white, with black speckles on edges.
• stderr has 31 texture ... (format 56) has mixed DCC keys ...; its texels are read as stored. Format 56 is RGBA8.
• Goat Simulator 3 (also UE4, discussion Goat Simulator 3 (PPSA04158) #10040) shows a similar exposure failure and the same kind of mixed-DCC-key messages.

Next: a DCC-key trace run (APS5_TRACE_DCC_KEYS=1) of the same path is queued. It should show which writes leave those keys mixed. Screenshots and logs are kept locally.