docs(wiki): 2026-11-14 status refresh - direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; STATE-CURRENT snapshot

1 files changed, 78 insertions, 44 deletions

diff --git a/wiki/Graphics-Execution.md b/wiki/Graphics-Execution.md
index 107044c..7879505 100644
--- a/wiki/Graphics-Execution.md
+++ b/wiki/Graphics-Execution.md
@@ -12,7 +12,7 @@
 > [`../docs/04-implementation/04-real-render-walls.md`](../docs/04-implementation/04-real-render-walls.md)
 > (the measured walls); the docs tree wins on disagreement.
 
-Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` observed end to
+Status: 2026-11-14, tree `master @ 339da842`. Tags: `[live]` observed end to
 end; `[wip]` partially built; `[wall]` current blocker; `[target]` defined
 success state; `[planned]` designed, not built.
 
@@ -95,15 +95,31 @@ fidelity:
    kernel-mode spin (a display-engine GET-past-PUT on a driver ring wrap) and
    the flip-event timeout are all fixed, and captured GL sections now
    execute on the engine (`GR LAUNCH submitted` / `GUEST GR LAUNCH OK`) with
-   the data window populated (`n_data` 0 -> 1024). What remains for the
-   client's own stream is **delivery**: the lookalike gate and the live-PA
-   bound fix (10 GiB raised to the registered guest-RAM top, 14 GiB) let the
-   client's 13+ GiB page directories walk and decode real GR method streams
-   (impossible before), but the GL setup push (59,556 bytes at VA `0x4001004`)
-   and the draw pushes (`0x4250000`/`0x4250110`) still resolve to
-   zero/implausible PAs because their user/UVM VAS is never registered, so no
-   draw section opens for `0xbeef0100` and the window stays black;
-   window/screen present is still the frontier (§6).
+   the data window populated (`n_data` 0 -> 1024). The direct-GL client's
+   submission is now **fully decoded**: no client push carries a
+   method-grammar draw header — its nine NV906F GPFIFO entries tile one
+   contiguous buffer and its per-frame work is carried as rewritten
+   data-block blobs plus small real state pushes (324/476/728 B, head
+   `90110087 80000800`) that invoke MME macros (the QMD-carrier hypothesis was
+   tested and refuted: the entry format has no QMD bit, the blob is not a QMD,
+   and no QMD magic exists in the 256 MiB BAR1). Delivery into the lane then
+   landed: a content-gated FB-shadow rescue (`e1eac368`) and the LOW-band
+   rescue (`b7f09616`) recover the recycled client pushes, the 324-B
+   draw-state push opens a `C597` section, is captured and marked for the
+   verbatim 3D lane (the first direct-GL stream3d marks), and with the golden
+   MME overlay satisfying the prelude gate it **reaches the engine**
+   (`GR LAUNCH submitted` + OK, MME-PRELUDE pack 1701 IR words, MME-GOLDEN
+   slot 0 accepted). The current wall is **MME macro completion**: the beef
+   lane's 2799-word packed program cannot complete inside its <=2048-word
+   block together with the 156-400-word draw window, so the load-only carrier
+   gate drops every beef window and `live_gen` never promotes; a multi-part
+   keep-window mechanism is committed default-off (`b44694b5`) and enabled in
+   the campaign parameters (`339da842`), with the A/B pending. RT routing was
+   tested and refuted as the store cause (RT0 bind verified 16x, still
+   `wrote=0`), and the `CODESRC` fault-park class is prevented (a suspect
+   program page is relocated to the engine-mapped window-0 shadow;
+   `17c7ed7c`). The window stays black; the window/screen present is still the
+   frontier (§6).
 
 ## 4. The channel and object picture
 
@@ -162,9 +178,9 @@ swaps, and the GR backend no longer times out (the pair-close/pair-safe
    frames and captured videos (45.4 s and 50 s), the RM write-lock holder
    (Xorg in the DDX vidheap scrub wait) is fixed (`df6e71bb`), the X
    DDX/ScreenInit stability walls are closed, and the direct-GL ring/USERD
-   machinery is hardened. The next step is delivering the direct-GL payload
-   (setup push at VA `0x4001004`, draws at `0x4250000`/`0x4250110`) by
-   registering its user/UVM VAS, and then the window/screen present path.
+   machinery is hardened. The next step is completing the direct-GL MME
+   macro program (multi-part keep-window A/B), then the window/screen present
+   path.
 
 During bring-up the module also carries a **diagnostics-only mirror** for apps
 that spin on a shared progress word; it exists so a run can proceed while the
@@ -173,23 +189,31 @@ requires it switched off, along with any external poke.
 
 ## 6. Where the frontier is (ranked walls)
 
-1. **Direct-GL command-stream delivery** `[wall]`. The ring/VAS anchor, the
-   lookalike gate (a dense repeating-pointer page is refused) and the live-PA
-   bound are now right: the bound was raised from a compile-time 10 GiB to the
-   registered guest-RAM top (14 GiB on the 12 GiB boots), so the client's
-   parked page directory at 13+ GiB walks and push bodies decode as **real GR
-   method streams** (`src=4 plausible=1`, e.g. `SET_SUBDEVICE_MASK` +
-   `LAUNCH_DMA`) — reads that were impossible before. The exact remaining gap
-   is registration: the GL setup push (59,556 bytes at VA `0x4001004`) and the
-   draw pushes (`0x4250000`/`0x4250110`) still resolve to zero/implausible
-   PAs, and a walk probe during `gl_frames` shows **no registered VAS maps
-   them** — the payloads live in the client's user/UVM VAS, which the service
-   never registers. Until that VAS is registered (or the payload set pinned
-   from the guest pagemap), no GL draw section opens for `0xbeef0100` and the
-   window stays black. Related finding: the engine-zero-write campaign showed
-   the store wall is upstream of the draw — the replayed 221-word window
-   contains no draw, and the front end was parking on a pre-poisoned CWD only
-   because of that (the CWD-clear fixes landed as hygiene, not as the cause).
+1. **Direct-GL MME macro completion** `[wall]`. Delivery to the lane is no
+   longer the gap: the submission is fully decoded (nine NV906F entries tile
+   one contiguous buffer; no method-grammar draw header exists; the per-frame
+   work is data-block blobs plus real state pushes that invoke MME macros),
+   the recycled pushes are recovered by the content-gated FB-shadow and
+   LOW-band rescues, the client's 324-B draw-state push opens a `C597`
+   section, is captured and marked for the verbatim 3D lane, and reaches the
+   engine with the golden MME overlay (`GR LAUNCH submitted` + OK,
+   MME-PRELUDE pack 1701 IR words, MME-GOLDEN slot 0 accepted). The wall is
+   the multi-part program gate: the beef lane's 2799-word packed MME program
+   cannot complete inside a <=2048-word block together with its 156-400-word
+   draw window, so the load-only carrier gate drops each beef window
+   (`MME-LOAD-ONLY carrier ... window=156 ... dropped`) and `live_gen` never
+   promotes. A multi-part keep-window mechanism is committed default-off
+   (`b44694b5`) and enabled in the campaign parameters (`339da842`); the A/B
+   is pending. Two hypotheses were closed on the way: the QMD-carrier theory
+   (refuted: the entry format has no QMD bit, the blob is not a QMD, no QMD
+   magic in 256 MiB BAR1) and RT routing (the clear targets RT0 while the
+   window binds RT1; binding RT0 is verified 16x with correct target/geometry
+   but the store still misses, 61/61 `wrote=0`) — the store wall is macro/
+   front-end execution, not reachability. Related reliability result: the
+   `CODESRC` fault-park class is prevented by relocating a suspect program
+   page to the engine-mapped window-0 shadow (`17c7ed7c`; one validated boot:
+   31 relocations, 51 GR launches, 79 GP_GET advances, 0 `FAULT_PDE`, 0
+   `WEDGE-REARM`, `backend_ok=35`).
 2. **Window/screen present** `[wall]`. The pbuffer and off-screen frame paths
    are proven (`pixel=ff0000ff`, 500/500 non-black frames, captured videos),
    but a windowed present does not land: glxgears' window is black, the DDX
@@ -201,12 +225,15 @@ requires it switched off, along with any external poke.
    the post-ScreenInit Xorg kernel-mode spin (display-engine GET-past-PUT on a
    driver ring wrap) and the flip-event timeout are fixed, and X has stayed
    green for >10 minutes in a validated window. What remains is a per-boot
-   **first-generation lottery**: only an X started immediately after boot
-   passes the DDX DMA init (3/7 windows), later DMA instances can still fail,
-   and the shared nvClip `modeNum` must be even for the GL client's state init
-   (an odd value is guest userspace X-driver state, cleared by one X restart —
-   not a host bug). Wrapped PUTs and the kick-idle marker/GET publication are
-   handled; a guest kernel panic after a wedge is recovered by an offline
+   **first-generation lottery** that became the dominant throughput limiter
+   for the graphics A/B runs: only an X started immediately after boot passes
+   the DDX DMA init (3/7 windows in one runoff; long dead-start stretches
+   later, with one green first-start boot, c382), later DMA instances can
+   still fail, and the shared nvClip `modeNum` must be even for the GL
+   client's state init (an odd value is guest userspace X-driver state,
+   cleared by one X restart — not a host bug). Wrapped PUTs and the kick-idle
+   marker/GET publication are handled; a guest kernel panic after a wedge is
+   recovered by an offline
    filesystem check.
 4. **Non-black window frames and sustained rate** `[wall]`/`[target]`. Once
    the command-stream delivery, the window/screen present and X screen-init
@@ -241,15 +268,20 @@ requires it switched off, along with any external poke.
 | X DDX idle-DMA/ScreenInit, USERD-latch lifetime, re-probe thrash, Xorg kernel-mode spin (GET-past-PUT) and flip-event walls closed; X green for >10 minutes (`13a0c5d6`, `acb51d53`, `6ebc7cd4`, `770d6b4a`, `b9213c57`, `29690635`) | `[live]` |
 | Captured GL sections execute on the engine (`GR LAUNCH submitted` / `GUEST GR LAUNCH OK`); data window populated (`n_data` 0 -> 1024) | `[live]` |
 | Client push bodies decode as real GR method streams above 10 GiB through the VAS walk (live-PA bound raised to the registered guest-RAM top, `436cbf9d`; lookalike gate `7d27df77`) | `[live]` |
+| Direct-GL submission fully decoded: nine NV906F entries tile one contiguous buffer; no method-grammar draw header in any push; per-frame work is data-block blobs + real state pushes (324/476/728 B) invoking MME macros; QMD-carrier hypothesis refuted | `[live]` |
+| Recycled direct-GL pushes recovered (content-gated FB-shadow rescue `e1eac368`, LOW-band rescue `b7f09616`); client draw-state push opens a `C597` section, captures and is marked for the verbatim 3D lane | `[live]` |
+| Direct-GL state push reaches the engine with the golden MME overlay (`GR LAUNCH submitted` + OK; MME-PRELUDE pack 1701 IR words; MME-GOLDEN slot 0 accepted) | `[live]` |
+| `CODESRC` fault-park class prevented: suspect program page relocated to the engine-mapped window-0 shadow (`17c7ed7c`; validated boot 31 relocations, 51 GR launches, 79 GP_GET advances, 0 `FAULT_PDE`, 0 `WEDGE-REARM`, `backend_ok=35`) | `[live]` |
+| RT routing tested and refuted as the store cause: RT0 bind verified 16x with correct target/geometry, still 61/61 `wrote=0` | `[live]` (negative result) |
 | GZDoom passes `V_Init: allocate screen` with GL 4.6.0 when shared nvClip `modeNum` is even | `[live]` |
 | RM write-lock holder identified (Xorg in the DDX vidheap scrub wait) and fixed (`df6e71bb`) | `[live]` |
 | GL section capture: the X channel's `0xC597` stream decoded | `[live]` |
 | Verbatim 3D method-stream replay retired by the engine (no MMU fault) | `[live]` |
 | Synthesized launch executes real `sm_75` SASS; Turing `V3` program header accepted | `[live]` |
 | Emulated FB/GART sizing traps fixed (FB info replies in KB; GART default 256 MiB), removing the 4 GiB guest-allocation class | `[live]` |
-| Direct-GL command-stream delivery (gl setup push at VA `0x4001004` and draws at `0x4250000`/`0x4250110`; the CE ring `0xbeef0101`) | `[wall]` — the payloads' user/UVM VAS is never registered, so they resolve to zero/implausible PAs and no section opens for `0xbeef0100` |
+| Direct-GL MME macro completion (multi-part keep-window: the 2799-word packed program + 156-400-word draw window cannot fit the <=2048-word block; `live_gen` never promotes) | `[wall]` — mechanism committed `b44694b5` (default off) and enabled in params (`339da842`); A/B pending |
 | Window/screen present produces non-black window pixels | `[wall]` |
-| X screen-init first-generation lottery (`modeNum` parity; only an immediately-post-boot X passes DDX DMA init) | `[wip]` |
+| X screen-init first-generation lottery (`modeNum` parity; only an immediately-post-boot X passes DDX DMA init; dominant throughput limiter) | `[wip]` |
 | Non-black screen pixels from the emulated vGPU's 3D pipeline | `[wall]` |
 | Windows/DirectX guests | `[planned]` |
 
@@ -263,12 +295,14 @@ requires it switched off, along with any external poke.
 * Display/KMS bring-up (NvKms, `/dev/dri`, X, a real GL context) is not a
   rendered-frame claim. GZDoom reaching `V_Init: allocate screen` proves the
   client's GL init and the direct-GL GR lane, not the game loop or a
-  presented frame; the direct-GL payload VAS is not registered, so the
-  client's draws do not reach the engine.
-* The engine-zero-write (NOWRITE) campaign is not a rendering result: it
-  proved the replay window it inspected carried no draw, and that the front
-  end was parking on a pre-poisoned CWD only as a consequence; the store wall
-  is upstream in push delivery, not a 3D-pipeline defect.
+  presented frame; the client's draw-state push reaches the engine, but the
+  MME macro program does not complete, so its draws do not store and the
+  window stays black.
+* The engine-zero-write (NOWRITE) campaign is not a rendering result: it and
+  the draw census together proved the submission is macro-driven (no
+  method-grammar draw header exists), that RT routing is not the cause, and
+  that the store wall is macro/front-end execution; they are measurements of
+  the wall, not a 3D-pipeline defect or a pixels claim.
 * No frame-rate or latency numbers: the scheduled measurement is defined
   (60 fps over 60 s, no forcing) but not yet met.