docs(wiki): refresh status to 436cbf9d - DDX/X-stability walls closed, sections execute, push bodies decode above 10 GiB; remaining wall = direct-GL payload delivery (setup push recycled; draws 0x4250000)

1 files changed, 64 insertions, 32 deletions

diff --git a/wiki/Graphics-Execution.md b/wiki/Graphics-Execution.md
index 38eab6c..107044c 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-12, tree `master @ 800c108f`. Tags: `[live]` observed end to
+Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` observed end to
 end; `[wip]` partially built; `[wall]` current blocker; `[target]` defined
 success state; `[planned]` designed, not built.
 
@@ -89,10 +89,20 @@ fidelity:
    ring/VAS anchor and USERD machinery are substantially hardened (verified
    page-directory discovery, per-rank content scans, eager push pins,
    client-allocated USERD resolution, foreign-USERD skip, aperture-aware
-   fallback, wrapped-PUT acceptance). What remains for the client's own
-   stream is **delivery**: its 59,556-byte setup push (GPU VA `0x4024004`) is
-   still not resolvable/readable host-side while the client's page-directory
-   incarnation churns, so no draw section opens and the window stays black;
+   fallback, wrapped-PUT acceptance), and the 11-12/11-13 wave closed the X
+   side of the path: the DDX idle-DMA/ScreenInit wall, the USERD-latch
+   lifetime, the same-pass re-probe thrash, the post-ScreenInit Xorg
+   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).
 
 ## 4. The channel and object picture
@@ -150,10 +160,11 @@ swaps, and the GR backend no longer times out (the pair-close/pair-safe
    zero), the DDX 3D replay renders and reads back a pbuffer pixel
    (`pixel=ff0000ff`), the off-screen frame path produced non-black animated
    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`), and the
-   direct-GL ring/USERD machinery is hardened. The next step is delivering the
-   direct-GL client's own **setup push** (59,556 bytes at VA `0x4024004`) and
-   then the window/screen present path.
+   (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.
 
 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
@@ -162,32 +173,46 @@ requires it switched off, along with any external poke.
 
 ## 6. Where the frontier is (ranked walls)
 
-1. **Direct-GL command-stream delivery** `[wall]`. The direct-GL ring/VAS
-   anchor is substantially hardened (verified-pair page-directory discovery,
-   per-rank content scans, eager push pins at the ring latch, client-allocated
-   USERD resolution with a foreign-USERD skip, aperture-aware wire fallback and
-   wrapped-PUT acceptance), but the client's own **59,556-byte setup push**
-   (GPU VA `0x4024004`) is still not resolvable or readable host-side while
-   the client's page-directory incarnation churns — the pages live in the
-   emulated FB aperture beyond the visible window, and the CE ring sibling
-   (`0xbeef0101`) resolves only intermittently. Until the setup push decodes,
-   no GL draw section opens and no `GR LAUNCH` is submitted for the direct
-   client: GZDoom spins in its GL pipeline after `V_Init` and the window stays
-   black.
+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).
 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
    shared-surface `gpuRefCount`/`lastKickoffRefCount` poll (W1) must be
    satisfied through a verified surface VA, and a synchronous window draw
    wedges X.
-3. **X screen-init and stability** `[wall]`. X startup is still a per-boot
-   lottery: the DDX can fail its idle-DMA check (`Failed to idle DMA` ->
-   `Failed to allocate notification memory` -> `Failed to allocate push
-   buffer` -> `ScreenInit failed`), and the shared nvClip `modeNum` must be
-   even for the GL client's state init to succeed (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.
+3. **X screen-init and stability** `[wip]` (was `[wall]`). The idle-DMA/
+   ScreenInit class, the USERD-latch lifetime, the same-pass re-probe thrash,
+   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
+   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
+   land, the capture must show motion in a window, then 60 fps in one VM with
+   no forcing, then two VMs on two mediated devices with non-black frames in
+   both.
 4. **Non-black window frames and sustained rate** `[wall]`/`[target]`. Once
    the command-stream delivery, the window/screen present and X screen-init
    land, the capture must show motion in a window, then 60 fps in one VM with
@@ -213,15 +238,18 @@ requires it switched off, along with any external poke.
 | Direct-GL GR ring `0xbeef0100` resolves; releases advance; ring/VAS anchor hardened (verified page-directory discovery, eager push pins, per-rank scans) | `[live]` |
 | Client-allocated USERD resolved from the channel's memory objects (`hUserdMemory`/`userdOffset`); foreign-USERD adoption skipped; aperture-aware wire fallback | `[live]` |
 | Guest adapter init with the all-sysmem instance configuration (`RMInstLoc`) — the BAR2-verify trap | `[live]` |
+| 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]` |
 | 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 (the 59,556-byte setup push at VA `0x4024004`; the CE ring `0xbeef0101`) | `[wall]` |
+| 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` |
 | Window/screen present produces non-black window pixels | `[wall]` |
-| X screen-init/stability (idle-DMA ScreenInit lottery, modeNum parity) | `[wall]` |
+| X screen-init first-generation lottery (`modeNum` parity; only an immediately-post-boot X passes DDX DMA init) | `[wip]` |
 | Non-black screen pixels from the emulated vGPU's 3D pipeline | `[wall]` |
 | Windows/DirectX guests | `[planned]` |
 
@@ -235,8 +263,12 @@ 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 setup push does not yet decode, so the
+  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.
 * No frame-rate or latency numbers: the scheduled measurement is defined
   (60 fps over 60 s, no forcing) but not yet met.