Repository navigation
AGC: MXGP 26 (PPSA30839) aborts on a compute shader that calls a function pointer read through a V# at the fixed address 0xF_E0040000 #6117
Description
MXGP 26: The Official Game (PPSA30839) aborts on one compute shader. It happens with pad input (repeated button presses from start-up), 44–139 s in, while the loading screen is up. A 120 s run without input never reached it:
[gpu] driver failure: compute shader 0x1327ca0000 (shader_1327ca0000.req): shader 0x1327ca0000 stage 0 (shader_1327ca0000.req): ShaderRecompiler::Recompile: computed/data-dependent s_swappc_b64 call target at program counter 0x00000134 is not statically resolvable
Every run with input stopped on the same 296-word program at the same PC; only the code address moves (0x13260c0000, 0x1327ca0000). Linux (Ubuntu 24.04, RTX 4070 Ti, NVIDIA 595.99.02, GCC 13.3, Release), main fa539dd plus a few open AGC PRs that don't touch control flow (#5937, #5975, #5982, #5910, #5956), relinked with --to-intel.
What the call reads. The 296-word wave64 shader builds the address 0xF_E0040000 from two s_mov_b32 literals into VCC. It loads a 16-byte V# from that address, then s_buffer_load_dwordx2 loads the call target at +0x20 and a second qword at +0x28. If the target is zero, an s_cmp_lg_u64 and s_cbranch_scc0 skip the s_swappc_b64. So it looks like an optional hook that is normally null.
Why it can't link. FindTableCalls accepts this shape only when the V# pointer is in user data. Here it is a constant address. 0xF_E0040000 is also unmapped in AnyPS5: gdb at the abort can't read it. The title doesn't map it either: the fixed-address sceKernelMapDirectMemory hints in its first 60 s are all at 0x10_7fc00000–0x11_00800000. Its binaries (eboot and the prx files) don't contain the 64-bit constant.
It sits just below the 0xFF0000000 that AnyPS5 uses as the default tessellation-factor ring, so it may be a system-provided area too. Does anyone know what a console maps at 0xF_E0040000? If it is a zeroed or empty table, a constant V# pointer could go through the same path as the user-data case. ReadTableCallees would find no targets, and the call would stay behind the title's own null check.
Separately, before the abort the same runs log [gpu] deferred write-back failed: BDA access failed: address=0x1226d10f75 instruction=0xa08 bytes=4 stage=4 reason=7 (an unaligned 4-byte atomic). I haven't looked into that yet.
AI-assisted: yes
Activity
fma-rc commentedon Oct 14, 2026
That address belongs to Sony's
libSceAgc, as tv7 found for Silent Hill: Townfall on PR 4706. In the PS5 12.00 modules, libSceAgcDriver maps a 2 MiB block at 0xF_E0000000 at init, and libSceAgc places its table at 0xF_E0040000 (it aborts if the table lands anywhere else). It zeroes six 16-byte slots there and fills slot 0 with a V# of stride 16 over eight{routine, 0}records. So on a console the +0x20 qword is not null: it points at one of Sony's built-in routines, and the call runs.#6160 maps that block, fills the table the same way with records that point at a routine that only returns, and links the call. With it 1348 Ex Voto gets past the same stop (a call at PC 0x130). I can't run MXGP 26 here, so it would help if you tried that branch. The unaligned atomic is a separate problem; Ex Voto logs it too.
MarcZX10 commentedon Oct 18, 2026
The function-table call path in this report appears to be covered by merged PR #6160: it maps the Sony AGC table at
0xF_E0040000, fills the eight stride-16 routine records, and links calls through that fixed-address V# (the same mechanism previously confirmed for Ex Voto). Could you retry MXGP 26 on currentmainwith the same input sequence and report whether the computeds_swappc_b64target now resolves? The earlier unaligned 4-byte deferred write-back failure is a separate issue and may remain after this call is fixed; please include whether it still appears in the new run.milescoviello commentedon Oct 18, 2026
@MarcZX10 thanks, and sorry for the slow answer. I'm rerunning MXGP 26 on current
main376c040, which has #6160 and also #6094 (unaligned 32-bit buffer atomics, the likely cause of thereason=7write-back failure). Same pad input from start-up, 140 s, 2 runs. I'll post whether the computeds_swappc_b64target resolves and whether the write-back failure still appears.AI-assisted: yes (Claude Code)
milescoviello commentedon Oct 18, 2026
@MarcZX10 confirmed: it's gone on current
main. Linux, RTX 4070 Ti (595.99.02),main400baa2 with no other PRs, MXGP 26 with the same repeated pad input from start-up, 140 s:computed/data-dependent s_swappc_b64 call target ... is not statically resolvable, and nodeferred write-back failed ... reason=7. So feat(agc): link calls through the AGC FS table #6160 resolves the call through the table, and fix(shader): act on the containing dword for unaligned 32-bit buffer atomics #6094 covers the unaligned 32-bit atomic.@fma-rc thanks for identifying the address as
libSceAgc's table at0xF_E0040000. That's what #6160 maps. Sorry for not answering at the time.I'll close this as fixed by #6160 and #6094.
AI-assisted: yes (Claude Code)