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, 20 insertions, 13 deletions

diff --git a/wiki/OpenGL.md b/wiki/OpenGL.md
index 0bcaae7..e9a1750 100644
--- a/wiki/OpenGL.md
+++ b/wiki/OpenGL.md
@@ -12,7 +12,7 @@
 > [`../docs/03-architecture/02-guest-stack-and-cudasw.md`](../docs/03-architecture/02-guest-stack-and-cudasw.md)
 > (the guest stack). The docs tree wins on disagreement.
 
-Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[live]` observed with the
+Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` observed with the
 stock guest driver; `[wip]` partial; `[wall]` current blocker; `[target]`
 defined success state.
 
@@ -86,14 +86,17 @@ Rated honestly, against the milestone ladder in the plan:
 | First non-black GPU-rendered frames: 500/500 off-screen 640x480 frames per run; 45.4 s video (`r1769`) and a 50 s capture (2026-11-12) | `[live]` |
 | 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]` |
+| 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 >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 via the VAS walk (live-PA bound raised to the registered guest-RAM top, `436cbf9d`) | `[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]` |
 | Engine executes a launch built from the captured section (real `sm_75` SASS retired) | `[live]` |
 | Verbatim 3D method-stream replay retired by the engine, no MMU fault | `[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; they resolve to zero/implausible PAs and no section opens for `0xbeef0100` |
 | Window/screen present produces non-black screen 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]` |
 | 60 fps sustained, no forcing (M-GL4) | `[target]` |
 
 ## 4. How OpenGL runs are verified
@@ -115,13 +118,17 @@ non-black through the mdev), M-GL4 (60 fps, no forcing), M-GL5 (two VMs, two
 mdevs), M-GL6 (split-screen video). The project sits **between M-GL1 and
 M-GL2, with M-GL2's off-screen half proven**: the display/KMS stack registers,
 X and the stock GLX path are fully green (`glxinfo -B` rc 0, ~520 FPS
-`glxgears`, Xorg WAIT 0), the direct-GL ring/USERD machinery is hardened, and
-the GPU-rendered pbuffer path produced non-black animated frames and captured
-videos (45.4 s and 50 s). The remaining gates are **delivery of the direct-GL
-client's own command stream** (its 59,556-byte setup push is not yet
-resolvable/readable host-side under the client's page-directory churn), the
-window/screen present path (glxgears' window is black and a window draw can
-wedge X), and X screen-init stability — then the first rendered screen frame.
+`glxgears`, Xorg WAIT 0), the DDX/X-stability walls were closed (X green for
+more than 10 minutes), the direct-GL ring/USERD machinery is hardened, and the
+GPU-rendered pbuffer path produced non-black animated frames and captured
+videos (45.4 s and 50 s). Captured GL sections now execute on the engine and
+the client's push bodies decode as real GR method streams above 10 GiB. The
+remaining gates are **delivery of the direct-GL client's own command stream**
+(the setup push at `0x4001004` and the draws at `0x4250000`/`0x4250110` still
+resolve to zero/implausible PAs because their user/UVM VAS is never
+registered), the window/screen present path (glxgears' window is black and a
+window draw can wedge X), and the X first-generation screen-init lottery —
+then the first rendered screen frame.
 
 ## 6. What is not claimed
 
@@ -129,9 +136,9 @@ wedge X), and X screen-init stability — then the first rendered screen frame.
   vGPU yet; every screen capture so far is black. The non-black frames and the
   videos (45.4 s and 50 s) come from the off-screen pbuffer path (pbuffer ->
   sysmem -> kvmfr ivshmem -> host reader), not from a windowed X screen
-  capture. The direct-GL client's setup push does not yet decode, its draws do
-  not reach the engine, a synchronous window draw wedges X, and X screen-init
-  is a per-boot lottery. Those are the current walls.
+  capture. The direct-GL payload VAS is not registered, its draws do not reach
+  the engine, a synchronous window draw wedges X, and X screen-init retains a
+  per-boot first-generation lottery. Those are the current walls.
 * GZDoom reaching `V_Init: allocate screen` is not a rendered-frame claim; it
   proves the client's GL init and the direct-GL GR lane, not the game loop or
   a presented frame.