Mortal Shell II (PPSA34008)

[JJenkx]

Tested Mortal Shell II (PPSA34008) natively on Linux 7.2.9 / Ryzen 9 7950X / Radeon RX 6650 XT, RADV Mesa 26.2.4. Unreal Engine. Short bring-up check.

Result

• main 6696def6e6: stops about 50 s in, during the intro movie, with what(): Videodec2: picture info is only implemented for H.264. The movie uses a VP9 Videodec2 decoder (codec=2382845) and asks for picture info through the generic sceVideodec2GetPictureInfo.
• main + fix(libSceVideodec2): answer the generic picture query for VP9 pictures #8839: the VP9 intro movie plays, then the "Welcome to Mortal Shell II" notice and the main menu (New Game / Options / Credits) render, with no stop up to the 300 s limit.

It runs at 0.1-0.2 FPS (frame p50 7.2 s with APS5_TRACE_SECONDS=150:30; the GPU is busy 3% of the time). The queue worker spends its time setting up compute dispatches (Vulkan.Dispatch.shader_resources / Resources.Complete, about 5 ms each). perf places that in ShaderResources::buildComplete → GuestBufferMemory::UploadFinish → takeHeapReferences (copying and comparing the heap mirror per dispatch) plus GuestMemory::WriteChanged. This is the same cost reported for Echoes of the End.

Not verified

Gameplay (New Game was not entered at this frame rate), audio by ear, and saves.

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

[JJenkx]

Windows data point (Windows 11 22621, RX 6700 XT, AMD driver 26.8.1, libraries from main 6c12024 plus #8839 for the intro movie). Here the title does not reach the menu. Every run ends 22-44 s in with VK_ERROR_DEVICE_LOST, and the System log shows Display event 4101 ("amduw23g ... stopped responding and has successfully recovered"). That is the Windows GPU timeout (TDR, 2 s default; TdrDelay unset).

What stalls:

• Not a runaway shader loop: APS5_LOOP_GUARD at 1000 or 100000 never trips. A limit of 8 avoids the reset only by cutting the work.
• Not an oversized dispatch: with APS5_NO_GPU_INDIRECT, the largest dispatch is 480x270x1. Not cross-queue waits either; those are polled on the CPU.
• With APS5_SYNC_DRAWS APS5_LOG_SYNC APS5_DRAIN_ALL APS5_BATCH_CAP=1 APS5_TRACE_DRAW_PROGRAMS and a local driver build that prints every recorded draw's size (not a PR), four runs end the same way. The last draw recorded before the reset is the second of only two host mesh-shader draws per run (vkCmdDrawMeshTasksEXT), with 23 groups and 1 instance. Its program address changes per run (0x18c0249000, 0x18c0051000, 0x18c03ad000, 0x18c00be000), and its fragment program also varies. Every other draw is small: at most 199 groups or 48 vertices x5 instances, and none indirect.
• APS5_PROFILE_GPU with one-item batches: the first 10 s total 160 ms of batch time over 623 batches, then one batch passes 2 s.

The 0.1-0.2 FPS on RADV above fits this. A frame there takes seconds, which the longer Linux GPU timeout tolerates and the Windows 2 s TDR does not. So this looks like one very slow mesh-shader draw rather than a hang. I have not yet dumped that mesh program (APS5_DUMP_SHADERS only writes draw requests on failure). The next step is its recompiled code.

AI-assisted: yes (Claude Code)

[JJenkx]

Follow-up from Windows: I tried AMD's Radeon GPU Detective on the reset (RGD 1.6.3 from the portable Radeon Developer Tool Suite 2026-10-02, RadeonDeveloperPanelCLI --mode crash, no install). It captures a dump at the TDR, standard and enhanced, but both say "no command buffers were in flight during the crash", with no page fault and no in-flight shader.

The cause is on our side and is worth knowing for any AMD crash analysis of AnyPS5. The process creates two VkDevices:

• a headless one, on first GPU use before VideoOut opens (make_shared<VulkanDevice>() in the Dispatch, Draw and ShaderRegistry paths);
• later, the windowed renderer (Presentation.cpp).

RGD attaches crash analysis only to the first. For the renderer it logs Failed to initialize crash analysis [<id> Vulkan], so the dump watches the idle headless device. To get a useful RGD dump, the windowed device would have to be the first device the process creates.

AI-assisted: yes (Claude Code)

[JJenkx]

Follow-up on the RGD note above. I tested whether the windowed device could be made the first VkDevice, using a local diagnostic AGC driver build (not a PR). In that build, every lazy headless-device site (Dispatch, Draw, DrawPrecheck, ShaderRegistry) first waits up to 60 s for the windowed device.

The window never arrives. The headless device is still created once the wait times out, and only then does VideoOut attach the window. Mortal Shell 2 submits GPU work and waits for it to finish before it opens VideoOut, so the headless device is needed and the reorder isn't viable for this title. In that build the run then stalls in windowed-device setup and dies at about 134 s instead of the usual ~31 s reset.

That leaves two ways to name the slow draw on AMD Windows:

• raise TdrDelay so the draw can finish and be timed;
• an RGD release that attaches to devices created after the first.

AI-assisted: yes (Claude Code)

[JJenkx]

Probably the same root cause as Code Violet (PPSA26528) on the same AMD Windows machine; details in #6256 (comment 19093581).

There, draw-level buffer markers put the reset in the title's first Nanite mesh draw. It's an attachment-less visibility-buffer raster pipeline, and it hangs whenever it exports at least one primitive, even culled or degenerate. With SetMeshOutputsEXT(n, 0) the draws complete. This mesh program (0x18c0260000, dumped earlier in this thread) is the one I used for the standalone harness. It doesn't reproduce outside the game with synthetic inputs, so the real bound buffers or the real fragment program are still needed.

AI-assisted: yes (Claude Code)

[JJenkx]

Follow-up on the AMD Windows reset, with Windows' GPU timeout raised: TdrDelay set to 60 s, then a reboot. Radeon RX 6700 XT, driver 26.10.1, main 0c6a5bd.

The stalled batch does not finish slowly. It is still running at every 5 s check, up to:

[gpu] recorded batch 360 still running on the GPU after 75 s (timeline wait)

The title then aborts at about 100 s on vkQueueSubmit recorder: Vulkan result -1 after the reset. As with Code Violet (#6256), which runs the same UE5 Nanite path and shows the same hang, this is a GPU hang in that batch, not a draw that needs more time.

Evidence (local): evidence/PPSA34008/run40-tdr60-main.

AI-assisted: yes (Claude Code)