Lies of P (PPSA10261) on Windows: freezes on the in-game loading screen (no exception; render thread polling) #5983

Activity

1. MarcZX10 commented on Oct 14, 2026

   

   MarcZX10

   on Oct 14, 2026

   Contributor

   More actions

   This report is pinned to main a453108cf, so the first useful check is whether the same loading-screen freeze still reproduces on current main. If it does, could you capture a run with APS5_PROFILE_GPU=1 through the stall and attach the final [gputime] lines, along with a fresh RenderThread 2 stack showing the guest caller around the polling loop? The profile includes GPU batch span and per-program time; paired with the caller stack, that should distinguish unfinished GPU work from the title polling after the queue goes idle. The current report does not identify a wait primitive or command, so a generic code change would be guesswork.
2. p3n1cillin commented on Oct 14, 2026

   

   p3n1cillin

   on Oct 14, 2026

   Author

   More actions

   Follow-up, ruling out one lead:

   • The default run has two WAIT_REG_MEM timeouts on queue 0x20 during start-up:

     queue 0x20 WAIT_REG_MEM at 0x1020f776a0 timed out after 1000ms (function 3 ref 0x1 mask 0xffffffff value 0x20f776c0)
       earlier write by queue 0x0 opcode 0x50 at 0x1020f776a0+0x4
       earlier write by queue 0x0 opcode 0x49 at 0x1020f776a0+0x4
       recorder: ... queue 0 dormant 1, completions pending 0, label due 0
     queue 0x20 WAIT_REG_MEM at 0x1021294d20 timed out after 1000ms (function 3 ref 0x1 mask 0xffffffff value 0x2128bd80)
     

   • With APS5_GPU_WAIT_TIMEOUT_MS=60000 those waits are satisfied (no timeout lines at all), so the label does arrive, just later than 1 s.
   • The title still freezes on the same loading screen. Captures at 200, 300, 400 and 500 s are byte-identical, so those early-running gated dispatches aren't what leaves it stuck.

   AI-assisted: yes (Claude Code)
3. simonbronk commented on Oct 14, 2026

   

   simonbronk

   on Oct 14, 2026

   Contributor

   More actions

   A second title with the same symptom: Onimusha: Way of the Sword (PPSA27836, RE Engine). Same setup: Windows 11 Pro 26200, RTX 5070, driver 617.42, WinLibs GCC 15.2.0, Release. It also happens on a453108cf. I have a good base and a bad base, which may help narrow it down.

   Good: a local branch on main 0b97f8b plus the title's PRs (#5769). It shows the health warning and the language menu at about 13 FPS. No WAIT_REG_MEM timeout over 15 minutes.

   Bad: a453108cf, e34c47921 and ed835aa76, each with the same PRs, rebased. After about 40 s, the screen stays black at 0.3 to 1 FPS, and WAIT_REG_MEM times out on queues 0x20 and 0x28. No exception:

   [gpu] queue 0x20 WAIT_REG_MEM_64 at 0x210c841420 timed out after 1000ms (function 3 ref 0x63 mask 0xffffffffffffffff value 0x1)
   [gpu]   recorder: table miss (refusal 0), open batch writes it 0, snapshot write overlaps 0, pending completion labels 0, write-back completions 0, pending label age -1.0 ms, write generation 59351 seen 59351, queue 0 dormant 0, completions pending 0, label due 0
   [gpu]   preceding packet SET_UCONFIG_REG 00000342 c8020021 0c841420
   [gpu]   preceding packet WAIT_REG_MEM_64 00000013 0c841420 00000021 00000063 00000000 ffffffff ffffffff 00000019
   

   The same address pattern repeats on queue 0x28 with value 0x2.

   Performance trace on a453108cf + PRs, warm caches (APS5_TRACE_SUMMARY_EVERY=20, window APS5_TRACE_SECONDS=100:20):

   • Intervals 0 to 41 s: p50 16.7 ms. From 41 s: p50 225 ms to 4 s, GPU busy only about 15 ms per present.
   • In the window, Driver.Packet.memory_wait is 1195 ms per frame. Waits run up to 3.1 s on queue worker 0x28 and 1.7 s on 0x0.
   • At the same time, queue worker 0x38 sits in Driver.WorkerWait.dequeue_order: 744 ms per frame, single waits of 1 to 3 s.
   • So one queue waits on a label while another waits for its turn, and the 1 s timeout is what lets them move on.

   Ruled out on the bad base: #5851, #5484, #5631, a revert of #5592 (videoout buffer labels), and #757/#758 (the stop is already on a453108cf). The queue ordering code (waitFree / orderReleased) didn't change between the two bases, so a change in what the titles submit is more likely, for example a new flip or label path. I haven't bisected the 0b97f8b..a453108 range yet (roughly 120 merges).

   Trace and summary lines available on request.

   AI-assisted: yes (Claude Code)
4. MarcZX10 commented on Oct 14, 2026

   

   MarcZX10

   on Oct 14, 2026

   Contributor

   More actions

   One narrow candidate for the reported good/bad comparison: 17984f8c53695578b1f437598ff6f4d5b4fed659 (perf(agc): start no collect epoch at a wait its own queue's stored label satisfies) is inside 0b97f8b9f..a453108cf and changes two returns in Driver::waitMemory: when storedSince finds a write from the waiting queue, it now leaves the collection epoch unbumped. That may be unrelated, and it is not a queue-ordering change; I mention it because the new trace shows WAIT_REG_MEM_64 timeouts. If you can cheaply do one controlled comparison on the bad base with only this commit reverted, the timeout/present metrics would tell us whether this wait-path optimization belongs in the bisect range. It would not establish a fix by itself.
5. p3n1cillin commented on Oct 14, 2026

   

   p3n1cillin

   on Oct 14, 2026

   Author

   More actions

   @MarcZX100 thanks. Results on current main 4c1de0c0c, same setup:

   • It still reproduces. It reaches the same loading screen, and captures at 300, 400 and 460 s are byte-identical.
   • APS5_PROFILE_GPU=1 stops it much earlier, before any window exists. The log ends 150 lines in, right after the shader registry's start-up messages, and no swapchain is created in 460 s. The same build without the variable starts normally. So I couldn't get the [gputime] lines through the stall; that looks like a separate start-up interaction with the GPU profiler.
   • RenderThread 2 during the freeze. Six samples a second apart: one in title code at 0x14048fb7d (test %r14d,%r14d), the other five in ZwWaitForMultipleObjects under libkernel's TimedWait::Condition::waitSignal. gdb can't unwind past waitSignal into the title. I scanned the stack for return addresses in the title's image, but the candidates don't follow call instructions, so I'm not reporting them as callers.

   If there's another profiler variable that doesn't affect start-up, I'll run it through the stall.

   AI-assisted: yes (Claude Code)
6. simonbronk commented on Oct 15, 2026

   

   simonbronk

   on Oct 15, 2026

   Contributor

   More actions

   Update for Onimusha: Way of the Sword (PPSA27836): the black screen is gone on main 0afa6a6. Same machine as before: Windows 11, RTX 5070, NVIDIA 617.42.

   With the same PRs on top, the title shows its start-up screens and the main menu, and reaches the New Game scene load. A few runs still log 1 to 4 WAIT_REG_MEM timeouts of 1000 ms during start-up, but presentation continues.

   So something between a453108cf and 0afa6a607 fixed it for this title. It may be worth retrying Lies of P on 0afa6a6 or later.