SILENT HILL: The Short Message (PPSA10112)

[klosixgaming-arch]

Existing thread

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

Title

SILENT HILL: The Short Message (PPSA10112)

Content version tested

01.000.001

AnyPS5 commit

main at 66702f1, no pull requests applied

System tested

Windows 11, WinLibs GCC 15.2.0, RTX 5090 (NVIDIA 617.42), AMD Ryzen 9 9950X3D

Furthest point

In game

What is shown

The game converts and runs to gameplay. It shows the intro brightness screen, the main menu, the New Game flow, a rendered intro movie and then the game itself: the camera moves, the player walks and opens doors. Frame rate: under 2 fps in the menu on the first run (shaders compile), about 8.6 fps in game. Entering a new room slows it down briefly while new shaders compile, then it returns to the same slow rate; the shader compile counts were nearly flat at the end of the run, so the steady rate is not shader compilation. I did not record audio or controller behaviour.

Current blocker

The frame rate in game (about 8.6 fps); the cause of the steady slow rate is not measured yet.

One run (of two) stopped about 136 s after start, right after the intro brightness setting was changed and the game saved /savedata0/ue4savegame.dpx.sav, with a null read on the async loading thread:

FATAL: unhandled exception 0xc0000005 on thread 60016 'FAsyncLoadingThread'
  rip 0x0000000141515c2f app.exe+0x1515c2f
  read of 0x0000000000000000

The code is the Unreal package loader reading a package header through a pointer to an all-zero buffer. I do not know the cause. The second run did the same steps and did not crash (it had APS5_TRACE_CALLS=libkernel set, so the timing differed), so it is not reproduced.

Logged without stopping the title: Project file not found: ../../../Shpc/Shpc.uproject (the dump has no Shpc.uproject).

How it was run

The dump's eboot.bin and its 40 bundled modules (sce_module/*.prx and prx/*.prx, the Wwise ak*.prx plug-ins and others) are SELF files (magic 4f153d1d); the dump also holds .esbak ELF backups next to them. I unwrapped all of them with tools/unwrap_self.py into a folder anyps5-elf (eboot.bin, sce_module/, prx/) and relinked with --windows --windows-diagnostics --trace-imports --registry --sce-module-path anyps5-elf anyps5-elf/eboot.bin app.exe. app0 holds the dump's shpc and sce_sys as junctions, plus copies of eboot.bin, ue4commandline.txt and contentids.json. The dump has no PlayGo files, so the run used APS5_PLAYGO_UNLISTED_CHUNKS=absent. ANYPS5_GPU=5090, VK_LOADER_DRIVERS_DISABLE=*dzn*. Unreal Engine 5 title (IoStore pakchunk0-ps5.ucas).

AI-assisted: yes. Written with AI assistance and reviewed by me.

[klosixgaming-arch]

Update: with APS5_STORE_AT_FLIP=1 the title reaches gameplay.

Furthest point: In game (past the menus, new game, walking around, opening doors). Left running for more than 70,000 frames with no stop. About 45 fps at the menus on a warm shader cache.

Blocker without the setting: on current main (2788ed5 and f1af6c5) the title stops at its title menu in every run on a warm shader cache:

FATAL: unhandled exception 0xc0000005 on thread 50116 'FAsyncLoadingThread'
  rip 0x0000000141515c2f app.exe+0x1515c2f
  read of 0x0000000000000000

The package header the loader reads there is all zero. In a local build that recorded the last 16,384 APR events, none of the APR reads wrote to that header; Oodle is linked into the eboot, so I take the zeroed header to be the title's own decompression output overwritten by a late storage-image store (the case APS5_STORE_AT_FLIP exists for, #1970). #6926 alone did not change the stop. The crash I reported in the first post (app.exe+0x1515c2f after the brightness screen) is the same one.

How it was run: main f1af6c5, otherwise as in the first post, plus APS5_STORE_AT_FLIP=1. Docs PR naming the title under that setting: #7358.

AI-assisted: yes. Written with AI assistance and reviewed by me.

[klosixgaming-arch]

Workaround for the stop at the title menu: set APS5_STORE_AT_FLIP=1 before starting the game.

Crash without the setting (main f1af6c5, warm shader cache, every run I made; the stop is at the title menu):

FATAL: unhandled exception 0xc0000005 on thread 50116 'FAsyncLoadingThread'
  rip 0x0000000141515c2f app.exe+0x1515c2f
  read of 0x0000000000000000

With APS5_STORE_AT_FLIP=1 (same build, same dump, nothing else changed): two runs, both past the menus and into the game. The second ran for more than 70,000 frames with no stop; the camera moves, the player walks and opens doors. Frame rate was about 45 fps at the menus on a warm shader cache; I did not record the in-game rate in these two runs (8.6 fps in the first post was on an older build).

What I measured

• The faulting code is the Unreal package loader reading a package header through a pointer to an all-zero buffer.
• A local build recording the last 16,384 APR events showed no APR read writing to that header, so it is not a missing read from the IoStore.
• fix(agc): land GPU writes over guest memory before a host write into it #6926 alone did not change the stop.

What I infer (not proven)

• Oodle is linked into the eboot, so I read the zeroed header as the title's own decompressed output being overwritten by a late store of a pending storage-image result. That is the case APS5_STORE_AT_FLIP is documented for (agc-driver: write-back drops GPU results of full 64 KiB blocks of 1920x1080 render targets (PPSA12544 backgrounds garbled) #1970). The setting stores pending results at each flip, and that was the only change between the crashing and the working runs.
• I have not identified which storage image's store covers the header, so I cannot say whether a code fix exists that makes the setting unnecessary.

How it was run: as in the first post, with main f1af6c5 and APS5_STORE_AT_FLIP=1 added.

AI-assisted: yes. Written with AI assistance and reviewed by me.

[isshininu]

First title that I relinked, feels pretty good to do the work of gods

[whamre]

Update from Windows 11 (26300), RTX 2080 SUPER 8 GB (NVIDIA 616.92), WinLibs GCC 15.2.0, Release, runs started without input and driven by APS5_PAD_INPUT_FILE (X every 8 s), 5 minutes each.

Intro stop, fixed. From 053034f41 (#7579) main stopped at the intro with storing storage image results pending over memory outside the write watch without the guest bytes saved before them is not implemented. #8265 reverted it and is merged; main at e9a5a0c84 doesn't show it (0 of 3 runs). The RoboCop fix that replaces it, fix/dcc-mip-store-pending, doesn't bring it back either (0 of 3, see #7579).

Loading stall. After the intro, 2 of 3 runs on e9a5a0c84 stall: frames grow to 20–30 s, and Unreal's GameThread timed out waiting for RenderThread after 120.00 secs ends the run. When a run gets through, it reaches the menu and New Game at about 1–3 s per frame. With APS5_PROFILE_DRAW=1, the stall is the address-space rebuild of address-based draws:

• While loading, the title changes the guest allocation registry 1,800–2,800 times per 10 s (mostly 64 KiB mappings), so the cached address space is rebuilt 300–500 times per 10 s ([address] … rebuilds: generation).
• Each rebuild walks every registered range and every host import. That cost grows with the registry: 0.6 ms per rebuild at about 4,200 ranges, 15–25 ms at about 14,000, and up to 62 ms in one run on 43a2abaf7.
• Slower draws stretch the loading, so more mappings land while drawing. Some runs never get out of that loop.

Details and numbers are on #1324. I haven't found a setting that avoids it.

Other costs once it loads: buffers of 2–4 MiB that start in one registered range and end inside the next are copied on the CPU for every draw that binds them ([bigbuf]); that's the case #5372 addresses. On this card the storage image cache also gets only 1804 MiB by default, which is too little for the menu scene; APS5_TEXTURE_CACHE_MIB=3600 avoids that (see #7862).

AI-assisted: yes.