Silent Hill 2 (PPSA08710)

[tharun634]

Tested

• Title: Silent Hill 2, PPSA08710, content version 01.005.000
• Host: Windows 11 (build 26300), Intel i9-14900HX, NVIDIA GeForce RTX 4080 Laptop (driver 32.0.16.1742). Built with WinLibs GCC 16.2.0, Release. Relinked with --windows --registry --to-intel.
• Build: origin/main at 556547da71, plus the two commits from open pull request fix(shader): load and store 16-bit data of converted packed images #11580 (e56b66d6af, 094ad84333). Without those, the title aborts earlier on reads or writes a converted float image with 16-bit data, which is not implemented, which is already GTA V (PPSA04264) stops when the save loads: compute shader reads or writes a converted float image with 16-bit data #11425.
• Last update: 2026-10-31

Status

The title reaches the "press any button" screen, plays the loading movies, and plays a cutscene. On the cutscene the window stays at about 0.2 frames per second. One earlier launch died in the async loader before that cutscene. That stop did not happen on the launch that reached the cutscene.

Open items

	What	Seen
A	Access violation in FAsyncLoadingThread: mov eax, [rdx+rax*4] with rdx and rax both 0	1 launch, after the loading movie
B	Cutscene stays near 0.2 FPS; storage-image upload is about 1.2–1.7 s of GPU time per present	The launch that reached the cutscene

No open issue or pull request mentioned either of these for this title when this was posted. #11580 is the earlier 16-bit image stop and is already open. #6099 and #6189 describe storage images being uploaded again every frame on other titles; this capture does not show whether these are the same surfaces.

A. Async loader reads a zero export blob

FATAL: unhandled exception 0xc0000005 on thread FAsyncLoadingThread, rip app.exe+0x2558512 (guest VA 0x2548512). The instruction is mov (%rdx,%rax,4), %eax. rdx is the pointer at object+0x188, and it is null. r13 (0x3265360000) is the blob that pointer was built from, and the first 64 bytes of it are zero. r15 is r13+0x2c.

The function starts at guest VA 0x2548280 and the string .\Runtime/CoreUObject/Private/Serialization/AsyncLoading2.cpp is referenced inside it. The zero dword at r13+4 makes the following parse treat the payload length as 0 - 0x2c. The call that fills object+0x188 then leaves a null pointer, and the next instruction indexes it.

The same launch had already read the title's IoStore containers through APR, including pakchunk2-ps5.ucas at offset 0xe3dae60d0 (about 57 GiB). A direct read of that offset returns container bytes (6e 43 6f 49 ...), so this stop is not a 32-bit file offset. The launch that reached the cutscene passed this point, so it is not every run.

Bink: Mismatched number of tracks opened. is printed for credits.bk2 and loadingloop.bk2. The check compares a track count at offset 0x38 of the opened object with 7, 8, or 9, prints the string at guest VA 0x686e22d, and continues. The movies and the later cutscene still play.

B. Cutscene frame time

The cutscene launch had APS5_TRACE_APR=1, so these numbers are not a clean performance capture. The storage-upload time below is GPU time, not the APR log.

Over 10 s windows with 2 presents (about 0.2 FPS), [present] reported GPU busy of about 4.1–5.5 s per present. One [gputime] window:

• storage-upload: 895 times, 2388.8 ms, 5875 MiB (1194 ms and 2938 MiB per present)
• storage-writeback: 550 times, 550.5 ms, 3939 MiB
• draw: 2244 times, 181 ms

A nearby [storage] window: first-use uploads 1108 / 8565 MiB, and write-backs on storage-image creation 317 / 3947 MiB. [draws] in one window spent 1575 ms in readTarget (about 1.0 million pages walked).

A formal report needs a warm APS5_TRACE_SECONDS capture without APS5_TRACE_APR, and tools/trace_digest.py on that trace. I have not made one yet.

AI-assisted: yes

[tharun634]

The same traced launch has two slow regimes. APS5_TRACE_APR=1 was set for the whole run, and the first window is still about 26 FPS, so the logging is not what drops the later windows.

Before the cutscene, present rate falls and stays near 2–3 FPS while DCC-key uploads dominate:

Window	Presents / 10 s	GPU busy / present	Storage traffic in that window
First	265	9.2 ms	CPU uploads 725 / 2939 MiB. No clear-key hand-over.
Next	90	37 ms	First-use 453 / 4495 MiB.
Collapse	11	709 ms	Keys 1128 / 15624 MiB. Storage-refresh write-backs 826 / 3010 MiB. Imported-buffer-region write-backs 1067 / 6813 MiB.
Sustained	35	208 ms	Keys 3395 / 33856 MiB. Storage-refresh write-backs 1899 / 8021 MiB. Imported-buffer-region write-backs 2443 / 11753 MiB. 2275 clear-key hand-overs, 227889 units superseded.

That sustained shape holds for several minutes: about 20–35 presents per 10 s, on the order of 17–33 GiB of keys uploads, 6–8 GiB of storage-refresh write-backs, and about 1000–2000 clear-key hand-overs. keys is the storage-image refresh path where the DCC keys no longer match the keys the image was uploaded with (Texture.cpp, the refresh that sets uploadReason to keys).

During the cutscene the shape changes. Hand-overs go to 0 and keys falls to about 0.2 GiB per 10 s. First-use uploads and storage-image-creation write-backs take over, about 7–16 GiB and 3–15 GiB per 10 s, with 1–2 presents and GPU busy of about 4–12 s. That is the 0.2 FPS in the post above.

So the cutscene cost is new images, and the earlier cost is images being uploaded again because their DCC keys changed, together with the clear-key hand-over. This run does not show whether those are the same surfaces each window. It is still not a tools/trace_digest.py capture.

[tharun634]

APS5_TRACE_DCC_KEYS=1 on the same build, with no other trace variable, for the stretch before the button press. About four minutes, 23,201 key-change refreshes.

Every one of them is uncompressed to a clear code: 17,862 to 0000, 4,230 to 0001, 669 to 1111, 434 to 1110, 6 to single. Nothing in the other direction shows up as a refresh. The way back is MarkDirty: the first write to an image whose uploaded keys are a clear code stores uncompressed keys over the whole surface and sets the uploaded keys to uncompressed (Texture.cpp). The next fill of the clear code is then a key change, and upload takes the fast-clear path, a vkCmdClearColorImage of the whole image with a full-pipeline barrier on either side. It does not read the texels. The byte count on that path is what the earlier windows report as keys.

The same surface comes back, not a stream of new ones. 755 distinct address+size pairs, 136 seen once, 309 seen 10 or more times, 83 seen 100 or more times. The busiest were 0x30adb10000+0x10000 (337), 0x30b1840000+0x12b0000 (294, about 18.7 MiB) and 0x30add10000+0x10000 (292). Alongside the refreshes: 27,622 uncompressed stores by first write, and 14,225 key fills over an image whose uploaded keys were already uncompressed.

So the 2–3 FPS regime is these images being cleared again each time the driver has just expanded their keys. APS5_KEYS_FILL_CLEAR records that clear at the fill instead, and was left off. It does not by itself stop the round trip: the next first write still expands the keys, and the next fill is a key change again. This run did not time the presents, and it is not a tools/trace_digest.py capture.

[tharun634]

APS5_TRACE_SUMMARY_EVERY=10 and APS5_PROFILE_GPU=1, nothing else, on the same build (094ad84333). The window is 3840x2160. tools/trace_digest.py for the steady stretch, after the opening:

Seconds	Presents / 10 s	Frame p50	GPU busy / present	Queue worker 0
43–53	31	318 ms	212 ms	99 %
73–83	31	326 ms	220 ms	99 %
114–124	33	308 ms	219 ms	99 %
144–154	32	308 ms	220 ms	99 %

The largest phase is Driver.Packet, about 430 ms a frame. Inside it, dispatch is about 230 ms and memory_wait (guest wait packets, opcodes 0x3c and 0x93) about 110 ms. Driver.Dispatch.capture_resources is about 100 ms. The GPU is busy for about 220 of the 310 ms frame, so a clear's barriers are inside that GPU time and do not cover the rest of the frame.

Narrowing those barriers is the wrong patch for this stretch: the worker is full recording dispatches. The clear-key loop from the previous note still accounts for the GPU time. It does not account for the frame.

[tharun634]

APS5_PROFILE_DRAW=1 and APS5_TRACE_SUMMARY_EVERY=10 on the same build, through the same stretch. A steady 10 s window on queue 0:

	Dispatches	Cache hits	Capture	Device call	Total
Direct	6344	2050 (32 %)	10 µs	282 µs	2.59 s
Indirect	2993	235 (8 %)	1006 µs	93 µs	4.28 s

The indirect capture time is the worker waiting on GPU writes. Over the same kind of window the capture profile moved by 57,936 captures, and by 332 words read one by one over a pending GPU write. Those 332 words waited 3.04 s, and the hook's GPU waits inside capture moved by 3.02 s. None of those words were served from a known value or read raw on evidence. 3.0 s of waiting is the whole indirect capture total (about 1000 µs times about 3000 dispatches).

So the 3 FPS frame's dispatch time splits in two. Direct dispatches are a device call of about 280 µs, about 2.6 s per 10 s. Indirect dispatches miss the cache and block the worker for about a millisecond each while a few hundred argument words are still a GPU write, about 4.3 s per 10 s. This is the same wait #5694 describes, on this title's indirect dispatches.

[tharun634]

The 45 s to 65 s stretch, with no input, is now a performance report with a clean APS5_TRACE_SECONDS=45:20 capture: #14055