Marvel's Wolverine (PPSA03671)

[mrfelek]

Content version tested: 01.001.005

AnyPS5 commit: main 665ad7d (2026-10-13) plus the open PRs #4934, #5005 and #4962, and a local port of the sceVideoOutGetOutputStatusWithVrr change of #3972 (that PR no longer merges). Only #4962 is needed for this title; the others were in the tree from a run of another title.

System tested: Ubuntu 26.10, GCC 15.3.0, RTX 3080 Ti (NVIDIA 615.71.09), Linux native, SDL audio via PipeWire.

Furthest point: start-up. The title loads, initialises, searches save data and starts preparing shaders. No frame is shown.

Current blocker:

1. libSceNpCppWebApi.prx is not in the dump (sce_module/ holds only libc.prx), so the converted executable stops at load with error while loading shared libraries: libSceNpCppWebApi.prx (Marvels Wolverine PPSA03671 Relies on consoles .prxs #1033). For these runs a copy of that module from another title's dump was supplied locally.
2. libcohtml.Prospero.prx and libRenoirCore.PS5.prx sit loose in the dump root, not in sce_module/; they have to be unwrapped from SELF and converted with the other modules, or the executable stops at load on them.
3. ./app.elf: symbol lookup error: undefined symbol: zBsgF0q8DIM (libScePad); PR feat(libScePad): declare the unknown import zBsgF0q8DIM #4962 declares it.
4. 131 shaders fail to prepare after registration, for example 0x11d0111000: SPIR-V emission failed: ... opcode=Barrier reason=s_barrier in a vertex program that accesses LDS or GDS or writes memory is not implemented. This is probably the GS_FAST_LAUNCH state of Marvel's Wolverine: draw with GS_FAST_LAUNCH=1 (VGT_SHADER_STAGES_EN=0x482030) after the intros; registered shader type 8 #3880 (PR feat(agc): decode GS_FAST_LAUNCH geometry with one point per subgroup #4702, not tested here).
5. Then a game thread segfaults with a call to address 0. In the core dump the call is call *-0x58(%rbp) in the title's own code (app.elf + 0x3f37ee8), through a table of 384 function pointers indexed by an id read from 16-byte records (id 0x14f here). Only the first 22 slots are filled, the rest are zero, and that path has no null check. The ids in neighbouring records are in the same range, so the table was expected to be filled earlier. I could not tell which step did not run; it may follow from the failed shaders in 4, which I have not tested.

How it was run:

• Input: eboot.bin, libcohtml.Prospero.prx and libRenoirCore.PS5.prx unwrapped from their SELF containers (the dump is already decrypted).
• relinker --registry src/eboot.elf app.elf with those modules in sce_module/, then copied build/core/libs/libs/*.prx to libs/, app0/ with symlinks to the dump plus the converted *.guest.prx.
• SDL_AUDIODRIVER=pipewire ./app.elf

Related: #1033, #3880. Written with AI assistance; the runs and logs are from my machine.

[ImHoppy]

Second data point, on Windows: it gets past start-up and renders, at about 2-3.5 fps. No crash in two 4-minute runs, and the call through address 0 from point 5 above did not happen here.

Content version tested: 01.001.005

AnyPS5 commit: main d167000 (2026-10-14) plus four local commits:

• a zBsgF0q8DIM stub for libScePad (same as feat(libScePad): declare the unknown import zBsgF0q8DIM #4962)
• stub exports for libSceNpCppWebApi (Marvels Wolverine PPSA03671 Relies on consoles .prxs #1033), so no module from another title is needed
• draws and dispatches whose shader cannot be translated or bound are dropped instead of failing (indirect dispatches included)
• SPIR-V validation is skipped for very large modules, plus a pinned shader cache version

System tested: Windows 11 (26200), RTX 5070 Ti (NVIDIA 616.64), relinker --windows.

Furthest point: the opening "Sony Interactive Entertainment presents" card and the game's own render loop. The title's RenderFrameIndex reached 500 in 240 s on a warm shader cache (1658 hits, 551 misses). Watched live, it shows about 3.5 fps.

What still fails (dropped, not fatal, with the commits above):

1. The s_barrier in a vertex program that accesses LDS from point 4, for example 0x11d0110500 and 0x11d0111000.
2. 32 indirect dispatches per run, mostly GetImageResource dword 0 is not a valid runtime value (image tables read at runtime offsets, which feat(agc): implement image and sampler tables indexed at runtime offsets #757 covers). One has a bindless image table of 6948 entries against a limit of 16.
3. Shader ... has unsupported registered shader type 8; it is not prepared at registration (warning).

On an older base (9a9bd3f, 2026-10-11) the same setup ran at about 0.27 fps. Most of that time went into rebuilding each dispatch's resources on the CPU, because the runtime-indexed tables change the cache key on every dispatch.

How it was run:

• eboot.bin plus the title's own prx files (libcohtml.Prospero.prx, libRenoirCore.PS5.prx, ...) unwrapped into a mods/ directory.
• relinker --windows --module-dir mods eboot.elf wolverine.exe, run from the directory above mods/. Without --module-dir it stops with Failed to load module ...libcohtml.Prospero.prx.

Related: #757, #1033, #4962

[mrfelek]

Linux result for this game, thanks @ImHoppy for the notes. Same build line as above: Linux, RTX 3080 Ti (NVIDIA 615.71.09), current main (43349d4) with #4702 and #4962 now merged.

The null-call crash was a path problem in my setup, not a driver bug. The game loads /app0/libcohtml.Prospero.prx and /app0/libRenoirCore.PS5.prx. The runtime then looks for <name>.guest.prx next to that path, and falls back to the original SELF file if it is missing. I had passed both modules to the relinker as extra modules, which puts the converted files in app0/sce_module/. The lookup missed them, the game printed Could not load cohtml library ... 80020002 and carried on, the UI library never registered its render-command handlers, and the first UI command called an empty slot (index 0x14f of a 384-entry table) -> call to address 0. With libcohtml.Prospero.prx.guest.prx and libRenoirCore.PS5.prx.guest.prx available in the app0 root, the crash is gone and the Marvel Games intro cinematic renders (about 18 FPS).

After that it needs drop-on-failure to survive (local only, I do not think it belongs upstream): dispatches, draws, the shader ABI resolve calls and the shader-preparation commit are skipped when they throw. With that the game stays up and renders a 3D scene (sky, clouds and a flipped/mirrored plane, about 2 FPS), but not much of the frame.

Why most of it is missing (248 shaders fail to prepare on main + drop patch):

• 92 GetSamplerResource dword 0 is not a valid runtime value (sampler read from a constant buffer at runtime)
• 36 GetImageResource dword 0 is not a valid runtime value (T# read from a constant buffer)
• 2 vertex programs with s_barrier that access LDS/GDS or write memory
• compute dispatches dropped with bindless image table has 6948 entries (0 materials), limit 16

Open PRs that target part of that. I merged #5188, #5620, #5550 and #5473 on top of main (#5089 conflicts with #5620 in ResourceMaterializer.cpp, so I left it out) and ran the same scene with a fresh shader cache: the GetImageResource failures go from 36 to 0, so #5188 does what it says on this game. They are replaced by bindless storage image tables are unsupported (13) and static bindless image capacity exceeded (4), i.e. the 16-entry table limit. The sampler failures are untouched (105), and the picture and frame rate do not change. So the remaining blockers look like runtime sampler descriptors, bindless storage image tables and the 16-entry limit (#1184 is the PR for the last one, currently conflicting).

AI-assisted; the runs are from my machine.

[mrfelek]

Update on current main (3b1ea78; #5188, #5550 and #5089 are now in), same setup as above (Linux, RTX 3080 Ti, fresh shader cache, with the local drop-on-failure patch): 242 shaders still fail to prepare, down from 248. The GetImageResource failures are gone (36 to 0), so #5188 does what it says here. What is left: 105 GetSamplerResource dword 0 is not a valid runtime value (a sampler read from a constant buffer at a runtime offset; I found no open PR for that pattern), 13 bindless storage image tables are unsupported, 4 static bindless image capacity exceeded, and 2 vertex programs with s_barrier that access LDS or write memory. #5089 did not change any of these counts on this title.

AI-assisted; the runs are from my machine.

[mrfelek]

Update on current main (e34c479, which now has the runtime-offset image and sampler tables from #757/#758 and the 64-bit-pointer image tables), same setup as above (Linux, RTX 3080 Ti with 12 GB, fresh shader cache, the local drop-on-failure change). The shader failures I listed before are gone:

	previous run (main 3b1ea78)	main e34c479
GetSamplerResource dword 0 is not a valid runtime value	105	0
bindless storage image tables are unsupported	13	0
static bindless image capacity exceeded	4	0
s_barrier in a vertex program that accesses LDS/GDS or writes memory	2	2
stencil-reference export needs VK_EXT_shader_stencil_export	1	1

(117 shaders now log "could not be prepared at registration (its s_swappc_b64 ... calls a computed target); preparing it when it is used": that is a deferred preparation notice, not a failure.) The game also runs much further: the log is about 155,000 lines against about 740 before.

It now runs out of GPU memory. On the 12 GB card VRAM is at 10.5 to 12 GB within 10 s of launch, FPS stays at 0.1 to 0.17, and after about 175 s the process aborts with AGC graphics: vkAllocateMemory presentation source: Vulkan result -2. Over 890 vkAllocateMemory ... Vulkan result -2 failures come first, mostly storage texture (the sampled texture "keeps the snapshot path") and then render target. I cannot tell from this whether the title wants more than 12 GB or whether memory is not released; a run on a GPU with 16 GB or more would show it, and so would a VRAM-over-time trace on one.

AI-assisted; the runs are from my machine.