Resident Evil Village (PPSA01556)

[EagleBearerYS]

Current status (updated 2026-10-13, 20:25 PT)

Content version tested: 01.210.000

AnyPS5 commit: stock main stopped at the first frame until #4949 merged (2026-10-13); it hasn't been retested on main since. The furthest point is on a local integration branch: main 18c438b (2026-10-13) plus the pull requests below and the local changes listed at the end.

System tested: Windows 11 Home (26300), AMD Ryzen 9 5900HS, NVIDIA GeForce RTX 3070 Laptop GPU (8 GB), 16 GB of RAM with a 32-40 GB page file, WinLibs GCC 15.2.0 r7, Release.

Furthest point: In game (first player control)

What is shown

• On main before fix(agc): start the sample location registers at their clear-state value #4949: it stopped about 20 s in, at the first presented frame, with missing register in context bank at DWORD 0x2fe (766). Resident Evil 4 stopped the same way (Resident Evil 4 (PPSA07411): start-up needs a library named Party.prx; with the missing exports added it stops at sce::Json::InitParameter2::setSpecialFloatFormatType #2776).
• With the changes below, the game first shows a black screen while it creates its whole PSO cache (about 6,000 shaders). Then it shows:
  • the health warning, and the RE Engine and SpeedTree logos;
  • the autosave notice, Initial Settings, Accessibility Options (with its rendered preview) and brightness calibration;
  • the data-sharing prompt, the DLC notices, the add-on check and the VR Mode question.
• After that question, the first scene load completes in about 2 minutes with a warm shader cache. The title screen draws its 3D forest background, with the Extra Content Shop voucher dialogs.
• Then "Start Game", the DLC notices, View Mode and the main menu (New Game, Options, Bonuses, VR Mode, PlayStation Store).
• New Game on Standard: the opening storybook sequence plays in real time, to its end. It can also be skipped from the Options menu.
• After the storybook, the next scene loads for about 15 minutes on a dark screen. Then the first 3D scene plays: a cutscene, at about 0.5 frames per second. Holding Options for about 5 s opens its pause menu (Skip / Photo Mode / Skip cutscene).
• After the skip, the game autosaves and loads for about 13 minutes on a black screen. Then the player has control, with the "L: Walk" tutorial prompt: the left stick walks and clears the prompt, and the right stick turns the view.
• Saves are written, and they load.
• Frame rates:
  • the menus before the scene load: about 5 frames per second;
  • the title screen: about 0.3 with the pull requests alone, and about 0.9 with the local changes listed at the end;
  • the storybook: about 3;
  • the first 3D scene: about 0.35, and about 0.5 with the latest local changes;
  • first player control: about 0.65.
• Wrong output:
  • The first 3D scene, both the cutscene and the playable part, renders as a full-screen out-of-focus blur: only the lights show, as large bokeh discs. The depth of field pass reading a wrong or cleared depth target is the first suspect.
  • The brightness screen's two reference pictures are missing.
  • White triangle shards cover the lower right of the title background, probably from the local checkerboard approximations.

Current blockers

• The blurred 3D scene (see Wrong output): the game can be played by input but not seen.

• Speed in the first 3D scene:

  • The CPU side: one AGC queue worker is the limit, at about 1.5 ms of CPU per draw packet. Most draws bind a BDA page table, so their resources are never reusable (perf(agc): skip the resource-cache key and lookup for address-based draws #2657) and are rebuilt for every draw. That's the same single-worker limit as perf: RDR gameplay at 2.6 FPS, single queue worker CPU-bound #5345, with a different cause.
  • The GPU side: busy about 0.5 s per presented frame.

• The stop after the opening: on the move to the first playable scene, the Wwise thread AK::EventManager hit an access violation (0xc0000005) walking a list whose record has every qword shifted by 4 bytes. It happened in 2 of 2 runs before this PC's commit limit was raised, and in none of the runs that got past that point since. The cause isn't known.

• Shader preparation memory: preparing all the PSO cache's shaders at registration needs more commit than this PC had free, even with perf(shader): keep only evaluable branch conditions in resource plans #5181. Locally, preparing each shader at its first draw instead gets past it. That is an experiment, not proposed.

• Checkerboard rendering: the scene load uses two-sample checkerboard rendering:

  • sample locations that vary between pixels (2 samples at x ±4/16, swapped on odd rows; this GPU reports a 1x1 sample location grid);
  • two-sample rasterization into one-sample depth and color targets.

  Both are approximated locally and not proposed.

• Material textures chosen per lane: some mesh and vertex programs pick their T# in a waterfall loop keyed per lane. Bindless tables (16 slots, 32-byte records) cannot capture them. Locally they are planned as null images, which gives wrong output.

Pull requests

PR	Fixes
#4949 (merged)	First-frame stop on the unwritten sample-location registers (0x2fe)
#4883	Shader front-end plans in the disk cache: a warm boot reloads about 2,900 shaders in 32 s instead of a few minutes
#5181	Host memory of resource plans: at about 2,950 shaders, 11.1 GB without it and 5.8 GB with it
#4082 (merged)	Quad tessellation domains
#5234 (merged)	Integer tessellation partitioning (the same change was on the local branch)
#4172	Tessellation lowering, now with the branch-condition fix for lowerOwnLaneBits from its review
#5457	Hull programs with one input or one output control point (on #4222)
#5188	Image descriptors read from constant buffers at uniform offsets (mesh programs)
#5189	Wave64 half-wave reductions reading lane 63 (pixel programs)
#3965	The game protecting its whole main-thread stack with mprotect
#1186	Depth-plane arrays sampled from base slice 1
#5003	Storage access to the shadow depth arrays through 2D array views. A view from a later slice comes from a follow-up to #5003
#4515 (merged), #4517, #5249	Per-build copies of descriptor views over several imported ranges. With them, the first scene load passes at the default import budget
#4446	The host-visible heap past its budget during the first scene load (numbers in #4446)
#5052, #5640	A boot crash in 2 of 5 boots: GameThread reads a null pointer at app.exe+0x69cb959 after a frameless leaf's red zone was overwritten when a write fault was resumed (#361). #5052 frames none of this title's 3,036 red-zone leaves; #5640, on #5052, frames 2,132 of them, and no boot crashed in 12

Also on the local branch: Celegans12's open tessellation PRs #4201 and #4222 (#4114 and #4163 are merged), #2589 (scheduling of shader preparation), #4693, and #4876 (merged).

Local changes not proposed

• Shaders prepared at their first draw instead of at registration.

• Per-lane T#s planned as null images.

• The checkerboard approximations above.

• feat(agc): sample depth plane arrays from a later base slice #1186's commit, adapted by hand to the current DepthPlaneCopy.

• feat(agc): storage image access to depth planes through 2D array views #5003's later-slice view (a follow-up to feat(agc): storage image access to depth planes through 2D array views #5003 is being tried in its place).

• Memory experiments for speed:

  • host imports capped at 256 MiB per registered range, so the four biggest ranges (3 GiB) become heap mirrors in host-visible video memory;
  • descriptor views inside a heap mirror bound to the mirror instead of copied;
  • a cache of read-only descriptor views.

  Together they took the title screen from about 0.3 to about 0.8 frames per second.

• The Windows write collect skips the per-view check over ranges it already knows are clean. With every address-based build refreshing the 3 GiB of heap mirrors, that took the title screen from 0.82 to 0.92 frames per second in an A/B. perf(libc): walk shared views in order and remember collectable ranges in Windows write collects #5062 and perf(libc): walk shared views by iterator and remember clean pages per run in the write collect #3864 target the same lookups, and perf(libc): walk shared views in order and remember collectable ranges in Windows write collects #5062 is being compared.

How it was run

• Relinked with --windows --frame-red-zone from the dump's fake-signed eboot.bin and sce_module/libc.prx, unwrapped. The .esbak copies next to them hold the same segments.
• APS5_NO_GPL=1 (pipeline libraries off) keeps about 2.5 GB less during the PSO cache build.
• Menus driven with a pad command file.
• The first 3D scene needs more commit than 16 GB of RAM and a small page file give. With a 32-40 GB page file it holds about 14.8 GB of private memory.