G17P Mesa: the USC window base container needs a terminating CODE block (fragment-end page fault, found on M4 Pro)

[jgoyvaerts]

Summary. With the G17P Mesa (agx3b at dba15302), every render after the first fails on an M4 Pro (T6040, J616s, firmware 25G83). The cause is the USC window base page that agx_open_device() maps for G17P. It holds only the 0x340-byte container lead and then zeros. At the end of every fragment pass, the shader core executes from the first CODE block slot after the lead and keeps going until it reaches an END. Behind a bare lead it runs through the zeroed page into the unmapped guard page and takes a hard page fault. The fix is to follow the lead with one CODE block whose programs are a lone END (the m1n1 witness shape). With that fix, 102 consecutive renders are correct.

The same read probably happens on A18 Pro. Whether it shows up there depends on how unmapped reads are handled. The kernel advertises DRM_ASAHI_FEATURE_SOFT_FAULTS (default fault_control=0xb), but as far as I can see the G17 runtime never programs fault_control into the firmware. Could someone with an A18 Pro check whether a fault is being silently absorbed there?

Setup

• MacBook Pro 14" M4 Pro (J616s, T6040), GPU firmware 25G83 (interface ID shared with G17P, 0c8a_a322_0396_04c0).
• Kernel: a downstream port of aurora's drivers/gpu/drm/asahi G17 runtime to T6040, inert unless t6040_attach=1. Not public yet.
• Mesa: aurora-silicon/mesa agx3b dba15302, plus one local patch that admits T6040 as G17P. GL_RENDERER is "Apple A18 Pro (G17P B1)", GLES 3.2.
• Test: a surfaceless EGL/GLES2 program, 256x256 RGBA8. Frame 1: clear blue plus a red triangle, read back. Frame 2: clear green, read back. Then 100 frames ending in magenta, read back.

Symptom. Frame 1 reads back correct. The firmware then raises a recovery with reason 3 (page fault), blaming the fragment queue. The render's TA stamp is written, but its fragment-end stamp never is. Every later submit gets EIO.

The MMU fault registers at recovery time, decoded with regs.rs::get_fault_info for G14X+:

d8c0=00000081690b0211  -> valid, Unmapped, READ, unit 0x81 (UL1C), vm slot 5 (the client context)
d8c8=0000000400000100  -> address 0x100_0000_4000 = AGX_G17P_USC_WINDOW_BASE + 0x4000

0x4000 is the guard page that follows the 16 KiB "G17P USC window base" BO.

Bisect. I used a temporary env knob to map more pages at the base and to place AGX3 END (0e 00 00 00) at chosen offsets. Each row is a fresh client on the same boot.

Base area	Result
1 page, lead + zeros (current)	fault at base+0x4000
4 pages, lead + zeros	fault at base+0x10000
16 pages, lead + zeros	fault at base+0x40080
lead, END everywhere from 0x340	102 frames correct
END from offset 0 (no lead)	no fault, every pixel 0 (the lead itself is needed)
END only in 0x340..0x380	102 frames correct
END only in 0x380..0x3c0	102 frames correct
END only from 0x3c0	102 frames correct
lead + one CODE block with END programs	102 frames correct

So the fault follows the end of whatever is mapped, and any END at or after 0x340 stops it. Something enters at or before 0x340 and runs forward. This contradicts the comment in agx_device.c that the lead's own block-size dword "terminates the chain".

Fix (1 page as before; confirmed with default settings and with ASAHI_MESA_DEBUG=sync,nocompress, 102/102 frames each):

diff --git a/src/asahi/lib/agx_device.c b/src/asahi/lib/agx_device.c
index e0e3f695..e6fd9c9e 100644
--- a/src/asahi/lib/agx_device.c
+++ b/src/asahi/lib/agx_device.c
@@ -6,6 +6,8 @@
  */
 
 #include "agx_device.h"
+#include "agx3_code_container_core.h"
+#include "agx_ioto_program_core.h"
 #include "agx_g17p_bind0.h"
 #include "agx_linker.h"
 #include "agx_va_runtime_hole.h"
@@ -1349,9 +1351,15 @@ agx_open_device(void *memctx, struct agx_device *dev)
     * and a failing Honeykrisp one.
     *
     * The page carries the container's fixed leading block -- the same bytes
-    * both captured Apple code images start with -- and its own block-size
-    * dword terminates the chain, so it is a well-formed empty container
-    * rather than a blank page.
+    * both captured Apple code images start with -- followed by one CODE
+    * block whose constant and main programs are a lone END, the m1n1 witness
+    * shape.
+    *
+    * The lead alone is not enough on the M4 Pro (T6040): at the end of every
+    * fragment pass the shader core executes from the first CODE block slot
+    * after the lead and runs on until it reaches an END. Behind a bare lead
+    * it ran through the zeroed page into the unmapped guard page, a hard
+    * page fault that failed every render after the first.
     */
    if (dev->chip == AGX_CHIP_G17P) {
       const size_t usc_base_size = AIL_PAGESIZE;
@@ -1381,8 +1389,17 @@ agx_open_device(void *memctx, struct agx_device *dev)
          goto fail;
       }
 
+      static const uint8_t end_program[] = {0x0e, 0x00, 0x00, 0x00};
+
       memset(map, 0, usc_base_size);
       agx3_build_container_lead(map);
+      if (!agx3_build_code_block((uint8_t *)map + AGX3_CONTAINER_LEAD_SIZE,
+                                 usc_base_size - AGX3_CONTAINER_LEAD_SIZE,
+                                 end_program, sizeof(end_program),
+                                 sizeof(end_program), NULL, true)) {
+         fprintf(stderr, "Failed to build the USC window base container\n");
+         goto fail;
+      }
       agx_bo_assert_range(usc_base, 0, usc_base_size);
 
    }

The patch is free for anyone to take. I can also open it as a PR against agx3b if that's preferred.

Assisted-by: LLM (Claude). The analysis and patch were checked on the hardware above.