Hades II (PPSA36082)

[Raghav314]

Tested

Title: Hades II, PPSA36082, v01.006.000
Host:
Linux (CachyOS, kernel 7.2.9), Ryzen 7 7800X3D, 32 GB RAM.
RTX 4090 24 GB on the NVIDIA proprietary driver 615.71.09.
Relinked for Linux with the relinker from #1249, built with GCC 16.2.1.
Last update: 2026-10-11 (evening)

Status

Playable, with warm shader caches. On main 961b25f with the PRs below, it boots, loads a game and plays, with no skipped draws. Standing in the hub it now sits at the 60 fps cap (p95 frame 16.7 ms) with pipelined draws from #1201 on (APS5_PIPELINED_DRAWS=1). That's the original executable with its 512 MiB upload pool, no patches.

The level-load crash from yesterday is gone on main: #2647 gives guest threads their host stack room back. The one catch left is that it only boots when the shader caches are warm. More on that below.

Some things worth knowing about how the game runs:

• It ships its own libc.prx, libSceJobManager.prx, libSceNpCppWebApi.prx, libSceFontGsm.prx, libScePfs.prx and FMOD (libfmod.prx, libfmodstudio.prx). All of them load as guest modules from sce_module.
• Its bundled libc replaces malloc with an mspace over 1 GiB of direct memory, mapped CPU-only (3).
• It maps 6784 MiB of GPU memory (0x32): a 512 MiB upload pool, a 6 GiB heap and another 128 MiB.
• The upload pool is the tricky part. The loader only frees it after a GPU fence, so anything that slows the fences down makes it overflow during startup. With everything below and warm caches, it peaks at 330-390 MiB out of 512.

You need an import budget of at least 6784 MiB, so either #290 or APS5_HOST_IMPORT_MIB=8192. I run with the env var, since #290 doesn't merge cleanly with current main.

Everything it needs right now

All open unless marked otherwise.

Needed for	PRs
Booting	#290 or APS5_HOST_IMPORT_MIB=8192 (#861, #1249, #1367, #1905, #1959, #1960 and #1961 are merged)
Loading a game	nothing open (#1902, #1928, #2095, #2105 and #2647 are merged)
Rendering in gameplay	#419, #2121, #2132, and custom sample locations (#2169, or my branch feat/agc-msaa-sample-locations, which is written on #419). #419, #2121 and #2132 need a rebase on current main
Audio in menus	#3301
Speed in gameplay	#1810, #3231, #3237 (#2253 is merged). #494, #1193 and #1201 help a lot as well, but they need a rebase on current main; I tested my own local rebases of them (details below)

Speed in the hub

Standing still in the hub, 20 s of MangoHud each, warm caches. The first four rows are without draw profiling, the rest with APS5_PROFILE_DRAW on (which costs a few fps), each against a run of the row before in the same session:

Build	fps
main + rendering PRs + #3175	25.8
+ #1810	32.7
+ #494 (local rebase)	34.5
+ #1193 (local rebase)	38.6
+ #3231 (profiling on: 31.9 before)	37.0
+ #3237 (profiling on: 39.2 before)	43.1
+ only the user words a stage reads block #494's data hits (local, see #494; profiling on: 39.8 before)	46.7
+ #1201 pipelined draws (local rebase, APS5_PIPELINED_DRAWS=1)	59.9 (the 60 fps cap)

#3231 lets draws share a render pass (84% of them now continue one), and #3237 lets them reuse their descriptor sets (91% resource cache hits). Both had been blocked because nearly all of this game's shaders carry a fault buffer for guarded descriptor slots.

#494's data-only hits reused almost no stages here, because each sprite changes a user word its vertex stage never reads. Comparing only the words a stage reads took the reused stages from ~7k to ~200k per 10 s (numbers in my comment on #494).

With #1201 the draw recording moves to its own thread: the packet worker is at about 16 us per draw and the recording thread at about 8 us, so the hub is capped by vsync. One thing to know when combining #1201 with #419: the CB resolve pass ran ahead of queued draws, which made the characters flicker or go dark. Draining the pipeline before the pass fixes it (details in my comment on #1201).

Speed in menus and gameplay

The hub is capped at 60 now, but the item and boon pickup menus and busy fights still dip (~1000+ draws a frame there instead of ~700). In a pickup menu, profiling on, warm caches:

Build	fps
everything above + #3301	48.8
+ the #1201 recording thread spins up to 50 us before sleeping (local, described on #1201)	53.2
+ draw stages share their compiled result instead of copying it (local, the part of #1202 that applies)	58.7

The GPU is only about 37% busy here, so the limit is still the packet worker translating draws (about 13.6 us per draw). Next thing I'm trying is moving draw preparation onto helper threads (Michon's APS5_PARALLEL_DRAWS from his gta-v branch); my local port of it crashes at startup for now.

Cold cache vs warm cache

This is the main thing left for booting.

• Warm (the shader disk cache and the Vulkan pipeline cache already hold the startup shaders): it boots every time, and the pool peaks at about 330 MiB.
• Cold (first launch, a fresh cache folder, or the first launch after any recompiler change, since the cache folder is keyed on a hash of the recompiler sources): it overflows the upload pool 3.2-3.5 s in, every time I've tried.

Why: on a cold start, the graphics queue hits draws whose pipelines aren't compiled yet and sits in vkCreateGraphicsPipelines: about 65 ms for the worst one, and three new pipelines show up back to back. The loader's fence is behind those draws on the same queue, so it lands too late and the loader keeps staging until the pool runs out.

Also, the pipeline cache is only written when the game exits cleanly. A run that crashes never saves it, so retrying cold doesn't warm anything up. A run that gets past startup and exits normally does.

The fix is being done in #2242: compile the shader stages at registration, so a draw only links them. The maintainers went with VK_EXT_graphics_pipeline_library; phase A (#2636, linking from per-stage libraries), phase B1 (#2645, dynamic rendering), #2661 (fixed push slots) and #2713 (link-time optimization in the background) are merged. A cold start still overflows: one vertex shader compile at the draw (86-90 ms), which phase B moves to registration. Measurements are in #2242.

What's still broken

	Problem	Status
1	Cold start overflows the upload pool (see above)	#2242 (phase B)

What stopped it on main, and what fixed it

	Problem	Fixed by
Startup
1	Missing imports: sleep, sceKernelGetAvailableCpumask, sceVideoOutAllowOutputResolutionWqhdDetection, sceAudioInAsyncOpen, sceAgcSetSemaphoreMemory	upstream sleep, #801, #802, #910, #1019 (merged)
2	Crash in libSceNpCppWebApi's constructor. The bundled libc rejects mspace bases outside the PS5 address window, so its heap ends up null	#861 (merged)
3	Vulkan device creation fails on the NVIDIA proprietary driver (the dma-buf import probe)	#1329 (merged)
4	The executable's GPU-readable piece (mprotected 0x11) fails to pin, and later allocations on the device fail	#1051 (merged)
5	Upload pool overflow (memcpy to null at eboot 0x28fba9) when the first flip replaces the device	#1367 (merged)
6	Upload pool overflow: guest hash tables with a single bucket make every lookup slow (1.88 s until the first file open)	#1249 (merged)
7	Upload pool overflow: the first address-based draw tries to pin the 1 GiB CPU-only heap, and the pin fails. 0/3 runs reach the menu without the fix	#1905 (merged)
8	Upload pool overflow: the 6 GiB heap gets pinned on the same queue the loader's fence is waiting on, which takes about 1.8 s. 0/3 without the fix	#1961, plus #290 or APS5_HOST_IMPORT_MIB=8192
9	Upload pool overflow: specializing the SPIR-V of one compute shader takes about 200 ms at the fence. Its generic module is 11 MB (since #639). 0/4 without the fix	#1959 (merged)
10	Upload pool overflow: the resource loader takes about 372,000 write-protect faults every 400 ms. 1/5 without the fix	#1960 (merged)
11	FMOD audio aborts in sceAjmBatchJobSetResampleParameters	#1018 (merged)
Menu
12	display buffer reads mixed DCC keys	#788 (merged)
13	Black menu: a vertex shader reads a user data register the game never writes	#1037 (merged)
Loading a game
14	prepared shader artifact is missing for the requested static ABI: every draw without a pixel program misses its prepared variant (#1901)	#1902 (merged)
15	Then the rect-list pair of a prepared pixel shader is missing	#1928 (merged)
16	The game freezes for about 45 s while loading: sceAgcCreateInterpolantMapping → shader preparation, where computing post-dominators took most of the time	#2105 (merged)
17	unsupported color depth, dimension, resource level or metadata mode for a 512x1 1D color target	#2095 (merged)
Gameplay
18	Multisampled color and depth targets	#419
19	CB resolves read the wrong sample count (the game leaves PA_SC_AA_CONFIG at 0 and puts the count in the target)	#2121
20	Ghost copies around the character and her shadow: the game clears its 4x targets with a uniform fill of their color memory	#2132
21	Custom 4x sample locations (0x444cc4cc)	#2169 or feat/agc-msaa-sample-locations
22	About 2 fps: every draw copied its vertex and index ranges out of guest memory	#2253 (merged)
23	Linux page queries (describePages) are repeated for the same pages every frame	#1810
24	Crash loading into a level: since #1988 a guest thread gets only the stack it asks for, and shader ABI resolution on the game's loading thread overflowed it	#2647 (merged)
25	Rare crash on exit: AJM: decoding codec <garbage> is not implemented, AJM state freed while FMOD still runs	#1926 (merged)
26	Every draw ended its render pass: a shader's fault buffer counted as touching any guest memory	#3231
27	No draw reused its descriptor set, for the same reason	#3237
28	#494's data-only hits rebuilt almost every sprite stage: a user word the stage never reads differs per draw	local change, described on #494
29	One thread decodes and records every draw; with #1201 on top of #419 the CB resolve ran ahead of queued draws (flickering characters)	#1201 + a drain before the resolve pass, described on #1201
30	Audio cut out for 0.7-1.4 s on every option change in pickup menus: FMOD's Opus jobs state an input size of 0xFFFFFE74, and AJM copied ~4 GB per job	#3301

Notes

• The upload pool is 512 MiB on the console too. Before these fixes I played it locally with the pool patched bigger in the executable, which gets around most of 5-10. None of the numbers above use that patch.
• The game loads libfmod.prx and libfmodstudio.prx from /app0, so in my run folder those are links to the relinked copies in sce_module.
• I've only tested on Linux with the NVIDIA proprietary driver. I haven't tried Windows or AMD with this game yet.
• AI Assistance used