Severed Steel (PPSA05106)

[JJenkx]

Existing thread

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

Title

Severed Steel (PPSA05106)

Content version tested

01.000.000

AnyPS5 commit

• main 38d3c0858a with fix(agc): resolve and render a multisampled target through its sRGB twin format #8847 (12223bf208).
• The same build with libSceAgcDriver.prx from 38d3c0858a + fix(shader): link a table call whose V# is a slice of an s_load_dwordx8 or s_load_dwordx16 #8070.

System tested

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

Furthest point

Menus (campaign New Game)

What is shown

• On main it stops 24 s in, before any frame: ShaderRecompiler::Recompile: computed/data-dependent s_swappc_b64 call target at program counter 0x0000088c is not statically resolvable.
• With fix(shader): link a table call whose V# is a slice of an s_load_dwordx8 or s_load_dwordx16 #8070 that stop is gone: fix(shader): link a table call whose V# is a slice of an s_load_dwordx8 or s_load_dwordx16 #8070 (comment)
• This dump also needs APS5_PLAYGO_UNLISTED_CHUNKS=installed. With that it reaches the campaign "New Game" menu at about 2.8 FPS. The log shows the host import budget collapse that fix(agc): lower import budgets only on memory exhaustion #8091 addresses (24 vkAllocateMemory (-1000072003) failures).
• At 156 s it stops inside the title with Unreal's PS5 Out of Memory: AvailablePhysical: 0, UsedPhysical: 14180876288 and Ran out of memory allocating 2293760 bytes. Not investigated.

Gameplay and audio were not checked.

Current blocker

The recompiler stop (#8070). After that, an out-of-memory stop at 156 s, not investigated.

How it was run

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

Modules in sce_module are converted with the title.

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

[JJenkx]

More on the stop at about 156 s (PS5 Out of Memory, UsedPhysical about 14.2 GB). I looked into it on main 6ef5a1c4c9 + #8070 73c9c2a762, with APS5_PLAYGO_UNLISTED_CHUNKS=installed and Cross every 15 s. All 5 runs stop the same way at about 150 to 155 s. Linux 7.2.9, Radeon RX 6650 XT, RADV Mesa 26.2.4.

It is the game's own memory pool, filled by video frames. At start-up the title reserves all 13.5 GiB of direct memory in a few large sceKernelAllocateDirectMemory calls and manages it itself. It releases only 0.29 GiB to the kernel, so nothing leaks at the OS level. The pool sits at about 3.6 GiB on the New Game menu. From about 130 s, 10 GiB is mapped into it in under 25 s, mostly blocks of 0x90000 and 0x230000 bytes, until nothing is left.

A temporary stack scan at the allocation (not in any branch) shows one caller chain for every block in the flood, the same chain the title prints when it fails. It runs through the function that references the string ProcessVideo. The block sizes match video frames padded to 1024x576 and 2048x1120.

Where it starts. The New Game menu's background is newtitlesequencebw_downrez.mp4: H.264, 960x540, 29.97 fps, 121.4 s, no audio. The title calls sceAvPlayerSetAvSyncMode(1) (no AV sync), sceAvPlayerSetLooping(1) and sceAvPlayerStart. It reads sceAvPlayerCurrentTime once, at start, and paces frames itself.

Per-frame logging in libSceAvPlayer (also temporary) shows two phases:

• First pass: frames are taken in step with real time. For example, frame timestamp 60060 ms was taken when the player clock read 60496.
• After the loop at 121 s: timestamps restart at 0, the player clock is rebased to 0, and the warning event 0x806A00A1 (looping back) reaches the title's callback right after the first looped frame. The title then takes frames as fast as they decode. Frame timestamp 90791 was taken with the clock at 5909, about 280 frames per second, and every frame allocates a new sample. The game's frame counter stops at the same moment.

The title's frame loop calls sceAvPlayerGetVideoDataEx until a frame's timestamp (ms × 10000) passes the end of the time window it asked for. It has a separate branch for a timestamp lower than the previous one. After the loop no frame reaches the window end, so it drains each pass of the video.

Not established. Either:

• the console keeps video timestamps increasing across a loop when AV sync is off; or
• the title is meant to wrap its window when its main thread handles the queued looping event, which it does not do here because its frame loop has stalled.

I have no PS5 measurement or documentation for this, so I am not changing the timestamp behaviour in a PR. If anyone has a hardware trace of sceAvPlayerGetVideoDataEx timestamps around a loop with AV sync off, that would settle it.