God of War Ragnarök (PPSA08329)

[B-Howell]

Existing thread

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

Title

God of War Ragnarök (PPSA08329)

Content version tested

06.006.000

AnyPS5 commit

main f759e16, with no pull requests merged on top.

System tested

Relinker-only Release build on Ubuntu 22.04 (WSL2), GCC 11.4. The title doesn't convert, so no GPU or runtime was involved.

Furthest point

Does not convert

What is shown

Nothing. The relinker exits with code 2 before writing any output.

Current blocker

#12123. The title's bundled sce_module/libc.prx has one raw syscall at 0x116c84. It's an inline _umtx_op wait (syscall 454, op 2) with an argument layout that doesn't match FreeBSD: the address has bit 63 set and the timeout is passed in uaddr1. A PS5 measurement of that call is needed before it can be handled. --trap-sdk-syscall-stubs doesn't recognise it, and trapping it wouldn't help, because the game probably reaches this wait.

FAIL: Forbidden syscall instruction at code offset 0x116c84 (offset 0x116c84)
Input: .../sce_module/libc.prx

Open pull requests needed: none known yet.

How it was run

Only the executables were extracted from the package: eboot.bin, sce_module/libc.prx and sce_module/libSceJobManager.prx. All three were converted with each of these:

relinker --windows --to-intel --no-patches eboot.bin out/gwr.exe
relinker --windows --to-intel --no-patches --trap-sdk-syscall-stubs eboot.bin out/gwr.exe
relinker --to-intel --no-patches eboot.bin out/linux

All three stop on the same line. An earlier Windows build at main 9b197b6 refused at the same offset.

AI-assisted (Claude Code).

[B-Howell]

Update: boots, presents frames, then stops on a compute shader

Content version: 06.006.000 (PPSA08329)

AnyPS5 commit: main 6e9b9134f6, with #11617 (b5991e402f) and #10304 (e0d6e062a9) merged on top locally (5fdd90f476).

System: Windows 11 Pro 26300, Ryzen 7 7800X3D, 64 GB, NVIDIA RTX 4080 SUPER (driver 617.42), WinLibs GCC 15.2.0, Release.

Furthest point: in-game rendering starts. With a warm shader cache it presents 16 frames in the first 150 s, at about 10 s per frame (p50 9.4–9.9 s). The trace summary puts the time in Driver.Packet, and its busiest worker is at 100 %. The first dumped frame is a 960×540 image. On a cold shader cache, the main thread spends the first ~300 s waiting on the per-frame GPU label while about 2,400 shaders compile.

How it was run:

• Full package extracted with pkg-to-anyps5 (9,743 of 9,743 files at their listed sizes).
• Converted with relinker --windows --patches gwr-restore-plt.toml eboot.bin gwr.exe, using the patch file from relinker: God of War Ragnarök's bundled libc.prx has an inline _umtx_op wait (syscall 454) with a non-FreeBSD argument layout #12123 (comment). The syscall check stays on. That patch file restores two import stubs that this dump had redirected to inline stubs. No --skip-syscall-check.
• Background window, no controller input, bounded runs of 150–600 s.

Blockers found in order:

1. relinker: God of War Ragnarök's bundled libc.prx has an inline _umtx_op wait (syscall 454) with a non-FreeBSD argument layout #12123: the dump's patched libc.prx PLT slot. Worked around with the patch file above.
2. sceHttp2SetResolveRetry not implemented 5 s after start. Fixed by fix(libSceHttp2): retry a failed lookup the number of times sceHttp2SetResolveRetry sets #11617, which is open.
3. compute shader 0x1052054800: AGC graphics: guest buffer has no GPU owner at about 150 s on a cold cache. Fixed by fix(agc): keep buffer owners when a staged address space dissolves #10304, which is open. It didn't come back in 7 later runs with that PR.
4. Current blocker, reproduced twice at about 225 s:

   [gpu] driver failure: compute shader 0x10527b8200: AGC graphics: an image view of more array slices than maxImageArrayLayers is not implemented
   

   The view is a linear 1D array (dimension k1DArray, 256×1, format 1, tile 0, one mip) with slices 0..5119, which is 5,120 slices against the RTX 4080's limit of 2,048. It's the same compute shader that feat(shader): model ds_ordered_count swap #7429 got past for the EU copy (ds_ordered_count swap). ArrayLayerWindow only handles views of fewer than maxImageArrayLayers slices, and I found no open PR for a view this wide (fix(agc): bound sampled array views to guest allocations #9318 bounds sampled views to their allocation, and 1.25 MiB of slices is probably inside it).

Open pull requests needed: #11617, #10304, plus new work for blocker 4.

Not tested: Linux, AMD or Intel GPUs, the EU copy, any controller input or gameplay, and audio beyond the device opening. I didn't check what the first frames show beyond the dump's size. Speed was not compared with main.

AI-assisted (Claude Code).

[B-Howell]

Follow-up: what the maxImageArrayLayers stop needs, and where the 10 s frames go

Same setup as my previous comment: main 6e9b9134f6 + #11617 + #10304, Windows 11 Pro 26300, RTX 4080 SUPER 617.42, Ryzen 7 7800X3D.

How compute shader 0x10527b8200 uses the 1D array. I read the shader's MIMG words from guest memory and the IR from APS5_DUMP_IR=10527b8200 on a cold cache:

• It has 15 image operations. Nine are image_sample_lz with dim = 1D_ARRAY (pc 0x24c0, 0x27f4, 0x31f0, 0x33fc, 0x3cd0, 0x4df4, 0x51f8, 0x5608, 0x5684), which means a sampler, a normalized u and a layer coordinate. The others are a 3D sample at 0xd50, three 2D samples, and two 2D image_loads at 0x2bb4 and 0x2bbc.
• The rejected T# is a linear, single-mip 1D array: 256 texels wide, format 1, slices 0..5119, at 0x1055fadc00. The sample takes the layer from a VGPR, so any of the 5,120 slices can be read through one view.
• It stops in ArrayLayerWindow (libSceAgcDriver/Graphics/src/TextureTiling.cpp). That function only narrows a view that already starts past slice 0. With a base of 0 and 5,120 slices it throws, because the RTX 4080 reports maxImageArrayLayers = 2048.

Why I haven't implemented it. A Vulkan 1D-array view can't have more layers than the device allows, so this needs a different image shape. One option is a 2D image of 256×5120 (the layout matches for this linear surface), with the recompiler turning (u, layer) into (u, (clamp(round(layer)) + 0.5) / layers) and taking the layer count from the T# at run time. That would need a new runtime image mode in ResourceMaterializer and a matching image path in Texture.cpp. The sampled form also depends on bilinear filtering in v picking exactly one row at texel centres. I couldn't make that general and well tested in this pass, so I'm leaving it open as a design question. Should it be a 2D remap, splitting into several views, or a texel buffer?

Where the frame time goes (before the stop, warm cache, summary over 112–152 s, 4 presents, p50 9.5 s per frame):

• Driver.Packet takes 19.4 s per frame. Of that, Driver.Dispatch is 10.1 s (materialize 4.6 s, capture_resources 4.0 s) and Packet.memory_wait is 9.3 s.
• Queue workers 0x0 and 0x24 are about 99 % busy, 0x2c is idle, and the GPU is busy about 60 ms per present.
• Draws aren't the cost. APS5_TRACE_DRAW_CACHE=1 shows only about 17 draw lookups per 10 s, almost all missing on user words or pointers.
• APS5_TRACE_DISPATCH_CACHE=1 shows compute dispatches missing their cache on 1–2 user-data words (user[0] or user[2], which are per-dispatch SRT pointers). That's 188 of the first 200 reported misses on one word, 11 on two, 1 on three.
• With perf(agc): reuse user-data callee links and check a cached raw shader's range once #9899 merged too (it reuses user-data links for draws), p50 was 10.2–11.3 s against 9.0–9.9 s without it, so there's no gain in this scene. The cost is in compute dispatch materialization, which perf(agc): reuse user-data callee links and check a cached raw shader's range once #9899 doesn't touch.

Not tested: other GPUs, which slices the shader actually reads, the 2D-remap idea, and a dispatch-side version of #9899.

AI-assisted (Claude Code).

[B-Howell]

Progress: past 0x10527b8200 with a local workaround (not a fix)

The workaround was local only and won't be proposed. To see what comes after the maxImageArrayLayers stop, I clamped any array view wider than the device limit to its first maxImageArrayLayers slices (2,048 of 5,120 here), and recomputed the clamped view's guest size. Doing only the clamp led straight to AGC graphics: texture snapshot size mismatch. This is wrong for slices 2048 and up, so it can only show what the next stop is.

Setup: main 6e9b9134f6 + #11617 + #10304 + #9899 + that experiment. Windows 11 Pro 26300, RTX 4080 SUPER 617.42, Ryzen 7 7800X3D, warm shader cache, background window, Cross pressed through the pad command file from 260 s.

Result. The bounded 600 s run ended with no exception, abort or unimplemented function:

• It made 42 presents at about 10.3–11.5 s each (p50). One 54 s frame came at about 230 s while it loaded the intro level's assets (mid_chase100_intro, Freya and Thor voice banks).
• All 15 frames dumped through APS5_DUMP_FRAMES are entirely black (960×540). I can't tell whether that's a fade or loading screen or a rendering problem, given how slowly frames arrive.
• The only open failed lines are for files the package doesn't contain, such as sys_files.*.toc and #xx.audiopack.toc.

So the next blocker after the array view is speed, not a missing function. The same profile as before, from the trace summary:

• Driver.Packet takes 20–22 s per frame. Of that, Driver.Dispatch is about 10 s (materialize 4.6 s, capture_resources 4.0 s) and memory_wait is about 9 s.
• Queue workers 0x0 and 0x24 are at about 99 %; the GPU is busy about 40–160 ms per present.
• Compute dispatches miss their cache on SRT pointer user words (user[0] / user[2]). This is being looked at alongside the draw-side work, so I'm not opening a separate PR.

The maxImageArrayLayers question from my previous comment is still open: the 5,120-slice view needs a real implementation.

AI-assisted (Claude Code).

[B-Howell]

The maxImageArrayLayers stop: PR #12246, and the clamp experiment is dropped

Please disregard my previous comment's results: they came from a local clamp to 2,048 slices, which reads the wrong data for slices 2,048 and up. That workaround is abandoned and won't be proposed.

#12246 implements the general case instead. A sampled 1D array view with more than maxImageArrayLayers slices, read only by image_sample_lz or image_sample_l, is bound as a 2D image with each slice in two adjacent rows. The shader rounds and clamps the layer as Vulkan's array layer selection does, then samples on the boundary between the two copies, so filtering never mixes slices. Other uses of such a view still throw. The PR has the sources and the main/change GPU test logs, run with the Khronos validation layer (0 VUIDs).

GWR with it (main + #11617 + #10304 + #12246, Windows 11, RTX 4080 SUPER 617.42, warm shader cache, 600 s bound):

• Compute shader 0x10527b8200 no longer stops the run. Without the change, all 3 runs stopped there, 224–333 s after launch.
• It made 43 presents in 422 s of presenting, about 10 s per frame, until the run's own timed dump at 590 s.
• Dumped frames are still black. At this frame rate, the loading of the intro level hasn't finished within the run, so the next blocker is still speed (Driver.Packet, compute dispatch materialization) rather than a missing function.

Not tested: other GPUs, controller input, gameplay.

AI-assisted (Claude Code).

[B-Howell]

Correction, October 28: The causal/exclusion statements in this earlier report were too strong. Those captures did not establish exact backing/draw/presented-frame correspondence or prove that the final pass wrote black; sampled bytes also do not prove full-surface draw coverage. A later instrumented paired readback found nonzero RGB throughout the selected target backing after the identified draw/pass boundary. The capture closes the pass to insert a copy, so it does not prove identical uninstrumented scheduling or correct scene content. The observations below are historical, run-specific evidence; cache, synchronization and fade hypotheses are not globally ruled out by these checks. See the qualified paired-capture follow-up.

The "Ruled out" list and deductions that sampled buffers prove per-frame writes, correct FP16 export, or zero color at that export are withdrawn. The original text below is retained only as historical context. Correction by Codex; the original Claude Code attribution is retained.

Historical report; the deductions identified above are withdrawn

Why GWR's frame dumps are black: the game writes black, and the dumps report it correctly

Setup: main + #11617 + #10304 + #12246, Windows 11 Pro 26300, RTX 4080 SUPER 617.42, warm shader cache, runs of 150–400 s. A local print in CommitBufferGroup was used for the buffer details only; it is not part of any PR.

The dumps are not an artifact:

• The title registers three 3840×2160 display buffers with sceVideoOutRegisterBuffers2: pixel format 0x8100000000000000, tiling mode 0, no DCC, category uncompressed.
• With APS5_PROFILE_DRAW=1, every present comes from the resident render target: 17 presents from the resident image ... 0 not pending, 0 unsuitable. None falls back to stale guest memory.
• The default GPU dump, the CPU dump of guest memory (APS5_NO_GPU_DUMP=1) and a direct read of guest memory after APS5_STORE_AT_FLIP=1 all agree. The CPU dump was taken on a separate run (APS5_NO_GPU_DUMP=1 alone); the guest-memory read is from the store-at-flip run.
• In that read, every sampled pixel of all three buffers is 0xc0000000: the two top bits set and the other 30 bits zero. So the buffers are written every frame with opaque black; they are not left unwritten. In a 2:10:10:10 layout that is alpha 3 with RGB 0, but I haven't decoded the exact layout of format 0x8100000000000000.

What writes it. Per frame, queue 0 ends with two fullscreen triangles (APS5_TRACE_DRAWS, APS5_TRACE_DRAW_PROGRAMS):

1. Vertex 0x1051ef1700 with fragment 0x1051f2c500 writes a target at 0x261550000. Its contents aren't black: about six distinct dwords across the surface, which looks like packed data rather than a lit image.
2. Vertex 0x1051ef1700 with fragment 0x1051f58a00 writes the display buffer. This shader image_loads one T# at a five-tap cross pattern, then loads more resources from a constant table. I haven't yet identified which surfaces they are or what they hold.

The UI draws (vertex 0x10e4065c00 and 0x10e4067000) are DRAW_INDEX_INDIRECT. The instances=0 that APS5_TRACE_DRAWS prints for them is the unknown-count placeholder for indirect draws, not the real count. Every NUM_INSTANCES packet in the first 40 queue-0 submissions sets 1.

Not settled yet: a real black screen, or a wrong input to that final pass. At about 10 s per frame, the longest run produced 43 frames. If the title advances by a capped time step per frame, that is only around 1.5 s of game time, so a fade or loading screen is still possible. The next step is to resolve the T#s and constants of 0x1051f58a00 (for example an exposure or fade value written by a compute pass) and check whether one of them is zero or NaN.

AI-assisted (Claude Code).

[B-Howell]

Correction, October 28: The causal/exclusion statements in this earlier report were too strong. Those captures did not establish exact backing/draw/presented-frame correspondence or prove that the final pass wrote black; sampled bytes also do not prove full-surface draw coverage. A later instrumented paired readback found nonzero RGB throughout the selected target backing after the identified draw/pass boundary. The capture closes the pass to insert a copy, so it does not prove identical uninstrumented scheduling or correct scene content. The observations below are historical, run-specific evidence; cache, synchronization and fade hypotheses are not globally ruled out by these checks. See the qualified paired-capture follow-up.

The "Ruled out" list and deductions that sampled buffers prove per-frame writes, correct FP16 export, or zero color at that export are withdrawn. The original text below is retained only as historical context. Correction by Codex; the original Claude Code attribution is retained.

Historical report; the deductions identified above are withdrawn

Black frames, round 2: the final pass reads a non-black image and still writes black. Root cause not found yet

Same setup as before (main + #11617 + #10304 + #12246, RTX 4080 SUPER 617.42). I used local-only diagnostics that dump the final pass's SRT table and log the bindings of one address; they are not part of any PR.

The last pass of each frame. Vertex 0x1051ef1700 with fragment 0x1051f58a00:

• Five image_loads (op 0, DIM 2D, dmask 0x7, no d16/a16) from one T#. That T# is a 3840×2160 16_16_16_16_FLOAT image, tile 7, that alternates each frame between 0x2694d0000 and 0x265510000.
• In the IR this looks like a contrast-adaptive-sharpening-style min/max/sharpen, then a dither sample from a 512×512 texture, then max(0, x), then linear-to-sRGB (12.92 / 1.055·x^(1/2.4) − 0.055).
• The color is exported as two packed FP16 dwords (v_cvt_pkrtz), (R,G) and (B, 1.0).
• Constants in the table: 1.0 and 2.2 at +0x108. The values at +0xec..+0xf8 change every frame: ±7.5/±4.22 and two values that drift from 0.053/0.937 to 0.324/0.028. They look like dither offsets, not a fade scalar.

The input to that pass is not black:

• The image is the output of compute shader 0x10527f5e00 (480×270 groups). It reads 2688×1512 color, velocity and depth plus last frame's 3840×2160 history, i.e. temporal upscaling.
• That pass writes the image through the RGBA16-UINT storage view that the f16 rounding path selects for write-only stores of 16-bit float formats.
• After APS5_STORE_AT_FLIP=1, guest memory of both images holds plausible half floats (for example 1.53, 0.82, 0.99), with dozens of distinct values across the surface.
• The fragment shader binds it as a float sampled image (fragment set binding 68, 2D, format 71).

The display format and export are behaving as designed:

• Display buffer format 0x8100000000000000 is the 10-bit variant: A2R10G10B10 with alpha in bits 30–31 (DisplayBuffer.cpp).
• Every pixel is 0xc0000000: alpha 3 from the exported 1.0, so the FP16 export unpacks correctly, and R, G, B are 0.
• So the color reaching the export is about 0, even though the image it reads is not.

Ruled out:

• Stale texture cache: APS5_NO_TEXTURE_CACHE=1 is still black.
• Queue synchronization: APS5_DRAIN_ALL=1 with APS5_STORE_AT_FLIP=1 is still black.
• The store→load path for 16-bit float images: a local GPU test (compute image_store to 16_FLOAT, 16_16_FLOAT and 16_16_16_16_FLOAT, then image_load before any CPU flush) reads back exact values with the validation layer on and 0 VUIDs.
• A fade: nothing in the pass's constants ramps like one, and the image it reads is not black.

Next: run fragment shader 0x1051f58a00 in a draw-level GPU test with the captured SRT table and a known input image, to find which part of the path zeroes the color: image fetch, sharpening math, denormal-flush emulation, dither or export.

AI-assisted (Claude Code).

[B-Howell]

Live-stage capture and confined replay update

I followed the existing Windows integration with a bounded, no-input background capture. The owned process was intentionally stopped after collection (exit 126 after 40.9 s); this is not a gameplay or performance result.

• Both 1,024-byte reads at the watched fragment entry 0x1051f58a00 match the saved shader used by the private fixture, SHA-256 4b102518b1c7fa3c27d69366c211c2053ba630197489ad0d80168f52f3777d4a. The runtime draw trace identifies that fragment entry.
• The confined fixture produces nonblack RGB with known input textures. Four controlled values for the auxiliary buffer give the same output. The synthetic compute-float16-store to fragment-load control also passes. Those fixture runs loaded validation and reported no VUID messages.
• The short real capture saved a black first-frame thumbnail. After observing a presentation, I captured a stable SRT plus 64 KiB CPU prefixes at its HDR/dither descriptor bases and the auxiliary buffer. Interpreted as half-floats, all 32,768 HDR-prefix values are finite and nonzero; the auxiliary bytes are zero.

The important limitation is attribution: these are CPU snapshots observed after a presentation event, not exact-frame GPU-resident input captures. A stable SRT does not freeze texture contents. Initial and later SRTs are stored separately. The controlled fixture is not a faithful replay of the complete draw state, and neither it nor this short capture establishes the failure cause or a fix. The earlier final-pass diagnosis remains a hypothesis.

Next is comparing the actual resident input and complete color-attachment/draw state. No production workaround was added, and proprietary shader/input bytes remain private.

AI-assisted: Codex.

Additional controlled replay: overlaying the captured 64 KiB HDR/dither prefixes and using the later captured SRT also produces nonblack output: float RGB approximately (0.975586, 0.981445, 0.986816), and A2R10G10B10 output 0xfe6fb3f2 (998, 1004, 1010, alpha 3). All four synthetic/captured-prefix and float/packed cases pass with zero VUIDs. This uses a 32x8 target and only prefix-overlaid textures; uncaptured contents and remaining graphics state are still synthetic, so it is not a complete frame replay. The existing storage-dump selector emitted no files in a follow-up run; no GPU-resident input-content claim is made.

[B-Howell]

Further diagnostic evidence: the final fragment's input has now been read back from its actual GPU storage image, rather than inferred from guest-memory bytes.

The capture binds fragment entry 0x1051f58a00, framebuffer 0x271860000, source 0x265510000 and the invocation's exact eight SRT descriptor words to one queue/draw receipt. It produced the complete 3840×2160 RGBA16F image (66,355,200 bytes, SHA-256 befcf60c1dff5b04684289de533702dfc1de018b07254a4cd82592bbcbc914ac). All 8,294,400 pixels have finite, nonzero RGB values: R about 1.00488–1.00977, G 1.02148, B 1.03223–1.03711.

This rules out an all-zero source image for that captured draw. It does not show that the source is correct scene content, establish post-sampler colors, or identify the black-output cause. The separately collected first presented frame is black; it is not asserted to be the same frame as this input readback. The next boundary is the draw's output before presentation.

The readback mechanism and exact-selector controls were first exercised on synthetic data with validation. Initial correlated-readback attempts yielded no capture because I omitted the second flag required by driver correlation (APS5_CAPTURE_TRACE); those attempts were rejected, then the launch configuration was corrected. No workaround or rendering fix has been published. The runtime driver was restored after the owned capture.

AI-assisted: Codex.

[B-Howell]

Paired input/output capture follow-up for PPSA08329: the instrumented run now has completed readbacks for the same selected draw (token26, submission101, queue0, offset826, batch197), fragment 0x1051f58a00, target 0x271860000.

• Input: 3840x2160 RGBA16F, 66,355,200 bytes; all RGB values finite and nonzero, near 1.
• Target backing after the identified draw/pass boundary: 3840x2160 packed color, 33,177,600 bytes. Every RGB channel is nonzero in all 8,294,400 texels; three packed words occur, predominantly 0xffffffff. Backing format64, attachment-view format58 and guest format50 are recorded separately. Output SHA-256: 9cb99cba7ad3201f9a94d8ea4700081338d923a885c914293bc9a4d4b4fc187b.

This describes backing contents in an instrumented run: the capture closes the render pass to insert its copy, so identical scheduling in an uninstrumented run is unproven. There is no pre-draw sentinel/coverage proof that the selected draw wrote every texel. Correct scene content and correspondence to the separately captured black first-presented frame remain unverified. This does not establish a VideoOut cause, rendering fix or performance result.

Independent review checked payload hashes, matching draw identities, completion receipts, synthetic float/packed controls and source/deployment hashes. The original runtime driver is restored. The next diagnostic step is to follow the backing/frame identity through transfer and presentation. No rendering workaround has been pushed.

AI-assisted: yes (Codex).

[ZSWolt]

Linux/RADV report: in game, the opening sled ride renders, about 2 fps there

Content version: 06.006.000 (PPSA08329)

AnyPS5 commit: main 1408347b2e plus local branches, built as one local integration:

• feat(agc): read sampler border colours from the border colour table #6804 (border colour table, open PR). Without it the opening level stops with "border color table not implemented".
• fix(shader): serve ds_ordered_count in wave launch order #12944 (ds_ordered_count in wave launch order). Without it, a particle compute shader in the title-screen scene produced overlapping records, drawn as long streaks.
• About 30 small local branches that are not submitted yet (library functions, AGC/recompiler fixes). I'll list or submit them separately if they turn out to matter for this title.

System: Ubuntu 26.04.1 (Linux 7.0.0-38), Ryzen 5 9600X, 30 GB, AMD Radeon RX 9060 XT (RADV GFX1200, Mesa 26.0.8-1ubuntu0.3), GCC 15.2.0, Release.

Furthest point: In game.

What is shown:

• Logos, the main menu, a new game, the opening cutscene, then the sled ride in the forest up to and including the first fight with Freya.
• Terrain, trees, snow and characters render lit and complete in the frames I checked over about 950 gameplay frames.
• Scripted pad input through APS5_PAD_INPUT_FILE works.

Frame rate:

• In the heaviest part of the ride, about 2 fps with the settings under "How it was run".
• The driver is CPU-bound there. The busiest queue worker is about 95% busy, while the GPU is idle for most of each frame.

Two things that may help others here

1. Dark or black frames. Between main of about Oct 26 and Oct 28, our frames turned very dark and characters black (mean luma about 28 vs about 88 before). The cause was fix(agc): round 16-bit float image stores toward zero #8998: 16-bit float storage-image stores of D16 data converted data that was already f16 a second time and wrote 0. main has the fix since c3c947e9c1 ("keep the half bits of a 16-bit float image store's D16 data"). I can't tell whether the black frames reported above have the same cause, but builds that contain fix(agc): round 16-bit float image stores toward zero #8998 and not yet c3c947e9c1 show this.
2. Saves made by older builds. Our saves made on Oct 20–21 start past the doorway load-zone trigger of the opening level. With them, mid_chase200_sledride.wad never loads, so the ground of the sled ride is missing. A new game from an empty save directory triggers the zone normally.

Current state and blockers:

• No stop in the part that was played (about 15 minutes, bounded runs).
• Speed is the open problem. Recording runs on one committer thread under the global GPU mutex, which is held about 70% of the time in this scene.

How it was run:

relinker --registry app0/eboot.bin app.elf
APS5_DRAW_PIPELINE=1 APS5_PIPELINED_DRAWS=32 APS5_PIPELINE_DISPATCH=1 APS5_RESULT_MEMO_MB=1024 \
APS5_WINDOW_MAXIMIZED=1 APS5_PAD_INPUT_FILE=/tmp/anyps5-pad ANYPS5_GPU=9060 ./app.elf

• APS5_WINDOW_MAXIMIZED is a small local change.
• APS5_RESULT_MEMO_MB=1024 cut result-memo misses from about 7–11K to about 2K per 10 s in this scene.
• The draw-pipeline switches together gave about +10–15%.

AI-assisted (Claude Code).