Repository navigation
Freeze after ~151k frames in Grotto (coming out of the water): RSX FIFO receives invalid command word (0x20438390) and park-resync loses the frame #7
Description
What happened?
The game froze mid-session after roughly 151,394 frames, while playing the Grotto level and coming out of the water. The log shows the RSX command FIFO hitting an illegal command word, a jump-park resync that recovered 172 fences but 0 label writes, and then no further frames. The 15 s and 60 s freeze watchdogs fired and the window exited. Main PPU sits at ~100% of a core inside game code while the render thread has nothing to consume and the SPU jobs are stalled.
A full memory dump is not required to triage this; the log already narrows it to an RSX FIFO corruption, most likely on the back of an over-capacity frame and an earlier SPU BRANCH-TO-0
Environment
Build: Ascension-R 0.1.0-alpha.3, port 9add610-dirty, ps3recomp v0.18.0-285-gef462282-dirty, clang 23.1.3
Game: NPUA80918, v01.12
OS: Windows 10.0.26300
CPU: i9-12900K (24 threads), 31.8 GB RAM
GPU 0: RTX 3080, driver 32.0.16.1088, 10053 MB
GPU 1: Intel UHD 770
Display: 2560×1440 @ 240 Hz
Preset/settings of note: render_scale = 2 (2560×1440 internal), scaling = bilinear, antialiasing = smaa, anisotropy = 16, async_shaders = 2, render_thread = on, pipeline_wait = on, frame_cap = off, vsync = on, patches.disable_shadows/MLAA/mesh_trimming/dof/motion_blur = on, steady_audio = on
What happened (timeline from logs/)
Frame under heavy load. The session ran well past 5.2M draw calls. Right before the stall, the per-frame index buffer overflowed repeatedly:
text
[D3D12] the frame's index buffer is full (4189689 of 4194304 indices, 4656 more asked): batches go to the CPU's conversion
[D3D12] the frame's index buffer is full (4194177 of 4194304 indices, 2760 more asked): batches go to the CPU's conversion
(4 occurrences back-to-back). The CPU-conversion fallback changes submission timing and memory traffic.
SPU lane faulted earlier in the same window.
text
[SPU] BRANCH-TO-0 unresolved pc=0x22A04 image=1465340752 lr=0x21F91
[SPU] branch-to-0 lr=0x21F91 r1=0x2385E
[SPU] dumped 256KB LS -> recomp_spu_ls.bin
GPR dump shows suspicious EA-like values in r52 = 0x73254380 0x70438410 0x00000080 0x320
05A8C
.
FIFO desync. The next command stream contains a non-command word:
text
[FIFODUMP] +0 io=00438390 w=20438390 <-- bad word
[cellGcmSys] FIFO resync (jump-park) 0x00438390 -> put 0x00AFC800
[cellGcmSys] resync rescued 172 fence(s) and 0 label write(s) from 0x00438390..0x00AFC800
The preceding [FIFOSTEP] io=00438390 w=20438390 type=1 method=0x0390 count=16 repeats ~60+ times with identical method/header before the bad word appears — plausibly a repeated SET_REPORT/GET_REPORT-region burst where get isn't advanced per step.
Freeze.
[freeze] no new frame for 15 s, 151394 frames so far → then 60 s.
Guest threads 2–5, 13, 14 in sys_lwcond_wait (waiting, not spinning).
Main PPU at ~100% of a core in ascension_game
.dll+0x27DC14B
(caller +0x20A6704).
Host rsx render idle in ntdll sleep — parked waiting for valid commands.
spurs pm one thread 23%, one 14%, rest idle.
Watchdog prints then [rsx] window closed, exiting.
Root-cause hypothesis
A very heavy frame stressed the command-submission path. Either a race in the FIFO put/write logic let a stale/partial word into the ring, or the earlier SPU job (the one that branch-to-0'd) wrote garbage into the FIFO region. The jump-park resync rescued 172 fences but 0 label writes, and the next put was 0x00AFC800 — far from the bad word — which is consistent with the ring being in an inconsistent state rather than simply "the game forgot to kick". The render thread then has no valid work, the game waits on a signal it will never get, the SPU lane that already died never recovers, and the frame clock stops.
The SPU BRANCH-TO-0 at pc=0x22A04 is a strong secondary candidate: if a SPU job that fills a command buffer went off the rails (wild pointer or bad lift), it could have written junk into the FIFO.
The Grotto water-exit moment is a plausible trigger because it combines heavy particle/water rendering with a camera/scene transition — exactly the kind of frame that would max out the index buffer and lean hard on the SPU jobs.
Evidence already available (no memdump needed)
logs/recomp_spu_ls.bin — 256 KB SPU local-store dump at pc=0x22A04, lr=0x21F91. Most useful artifact.
logs/missed_code.txt — 43 rows; relevant entries would point at recompiler lifting gaps.
The FIFO dump window io=0x00438340..0x00438390 (last ~20 valid words, then the bad one) is inline in the log.
Where in the game were you, and what were you doing?
Level: Grotto
Moment: exiting the water (the underwater-to-surface transition)
Frame: ~151,394
This is a scripted/transitional moment with heavy water and particle work, which lines up with the index-buffer overflow and SPU load described below.
Does it happen again?
Only once so far
Activity
rigaz29 commentedon Nov 11, 2026
Thanks for the detailed report, the log was enough to follow it.
The word at io 0x00438390 is not a bad command: 0x20438390 is a jump to itself, the stop the game writes at the end of its command buffer until an SPU job fills in the next commands. The job that should have filled it, one of the EDGE geometry jobs, ended early. Its last steps ran in the SPU interpreter (our build has no compiled copy of those paths; the first levels never take them), and from there it ran out of its own code. Without that job's commands and the label it writes, the resync can only skip the hole, and the main thread waits for the label for good.
Disable Mesh Trimming is likely part of it: the patch is in the compiled copy of the EDGE code only, the interpreter runs the original instruction, so a job that runs partly in each disagrees with itself about how many triangles it keeps. Your session without the patch had no "index buffer is full" lines; both with it had them.
For now, please switch off Disable Mesh Trimming (Game patches) and see whether the Grotto gets past that point.
To fix it for good we need to know which EDGE paths the Grotto runs. Could you please send both of these:
logs\missed_code.txt, the whole file as it is: it lists the code your sessions ran in the interpreter, and where it was loaded from.Offer frame generation off only when the GPU stopped behind it
glhj2814 commentedon Nov 11, 2026
missed_code.txt
report-20261111-094840.zip
Here are the requested file I'll try to see if turning off disable mesh trimming will un freeze the game
Update I got to the docks where the game froze again after turning off the patch for disable mesh trimming
report-20261111-102126.zip
missed_code.txt
Lift the job code only a pointer reaches; a report's saves load again
EDGE: e77C8's jobs start with no memo state (the Grotto freeze)
rigaz29 commentedon Nov 11, 2026
Thanks for trying it with Disable Mesh Trimming off: that ruled the patch out, and the register dump in your new report showed what was really going on.
The Grotto runs the second build of EDGE's geometry job, which the earlier levels don't use. Our native EDGE code keeps some state per thread while a geometry job runs, and only the first build's jobs cleared it when they started. So a job of the second build could start with what a job of the first build had left on the same thread, and act on it: it ran that other job's leftover work on its own memory, then returned to the wrong place. That broke the job, and the game waited for it for good. It depends on which jobs happen to follow one another on each thread, which is why it came every time on your PC and seldom on ours: with your save and your session played again, it froze here once in six runs.
0.1.0-alpha.6 clears that state at the start of every job of the second build too, and never runs one build's leftover work in the other's jobs: https://github.com/rigaz29/Ascension-R/releases/tag/v0.1.0-alpha.6. With your save, our check found no job of the second build seeing the other's state any more (12,652 times in one run before), and none of the runs since froze. It also compiles the part of that module that ran in the interpreter, so Disable Mesh Trimming now applies in both builds.
Please try the Grotto again with your usual settings and tell us whether it gets past. If it still freezes, a report from this version would help: its saves now load as they are. Before, the report left out the save's icon and the files' times, and the game refused them.
glhj2814 commentedon Nov 12, 2026
I was able to make it pass the grotto level without crashing now I'm at the cutscene of the Sparta illusion and I get this graphics glitch
rigaz29 commentedon Nov 12, 2026
Good to hear the Grotto plays through now, thanks for confirming the fix.
The new one: in that shot Kratos's skin comes out flat and too bright, while his beard, belt and armour look right and the other people's skin is fine. Something in the bottom right corner also has a garbled, multicoloured texture. Which version are you on (the launcher's sidebar shows it)? If it's 0.1.0-alpha.7, the log may also have
[vram]lines about it. A problem report made right after it happens, with "Include my saves" ticked, would let me load that cutscene here and see what's going wrong.glhj2814 commentedon Nov 12, 2026
I already passed it do you still want me to submit a report with the save?
rigaz29 commentedon Nov 12, 2026
Yes please, if it's no trouble. The report keeps the logs of your last few sessions, so the one where the cutscene looked wrong is probably still in it, and its log shows the version and anything the game or the port complained about there. Tick "Include my saves" too: even if the save is past that point, it lets me load the game where you are now. And if anything else looks wrong later, a report made right then helps the most.