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, 65 insertions, 5 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index b73d9b7..2fb0241 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,5 +1,64 @@
 # Open-IOV Current State
 
+> **Snapshot: 2026-11-14 ~10:55 (SESSION 157 continued; HEAD `339da842` ==
+> `vgpu/master`; working tree clean; supersedes the 2026-11-13 ~11:10 entry
+> below).**
+> The graphics front crossed the **push-delivery wall** and moved to **MME
+> macro completion**. 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 the 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, no QMD magic exists in 256 MiB BAR1). Delivery 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 wall is the MME multi-part program gate.** 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 (`MME-LOAD-ONLY carrier h=0xbeef0100 ... window=156 ...
+> dropped`) and `live_gen` never promotes (completion launches end
+> GP_GET-frozen / `MISSING_MACRO_DATA`+poison). 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: **RT routing** is not the store cause (the client clear targets RT0
+> while the window binds RT1; binding RT0 is verified 16x with correct
+> target/geometry, yet 61/61 launches still `wrote=0`) and the **QMD carrier**
+> theory is refuted; the `CODESRC` fault-park class is **prevented**
+> (`17c7ed7c`: a suspect program page is relocated to the engine-mapped
+> window-0 shadow, launch refused if mapping fails; one validated boot: 31
+> relocations, 51 GR launches, 79 GP_GET advances, 0 `FAULT_PDE`, 0
+> `WEDGE-REARM`, `backend_ok=35`, `fault=0`).
+>
+> **X start is now the throughput limiter.** The DDX/ScreenInit, USERD-latch,
+> re-probe, kernel-mode-spin and flip-event walls stay fixed when X starts
+> (validated >10-minute windows), but the first-generation start lottery is
+> frequent: eng29-eng37 saw long dead-start stretches (X-DEAD, GLX-hung,
+> ScreenInit-failed; 40+ dead starts in c374-c380, roughly 1/9 green), with
+> one first-start green boot (c382) validating RT0 bind. `gl_frames` remains
+> black (px0=0 x3 in c346, ~12-15 s/frame), `wrote=0`, and the off-screen
+> mission stays held.
+>
+> CUDA front unchanged (backgrounded while graphics holds the device; its
+> 10-30 status stands): `41343c63` green (`victory_mail` `VADD bad=0` +
+> `STATUS OK`; `vecadd_loop` 100 launches PASS); the fresh-boot battery's
+> red class is D2H-stage with release-discipline fixes staged; the SESSION
+> 143 Vulkan fence regression is not re-measured.
+>
+> Live at check (read-only): host uptime 1 d 15 h (fresh boot 2026-11-12
+> ~19:16); `vgsp` loaded (refcount 1) + mdev
+> `00dfe88e-0697-4aae-91fd-ddccfe584038` + QEMU cycle c402 (PID 241478,
+> 12 GiB file-backed guest, kvmfr ivshmem, launched 10:50; X start 10:51);
+> campaign knobs `partial_keep=N rt0=1 synth=Y grace=500`; `nvidia-smi`
+> reports no GPU (the claim is held); pstore empty; no Xid/Oops; no reboot
+> during the check. The open-iov.org wiki was refreshed alongside this
+> snapshot (11 pages, revs 24144-24154; 68 pages audited, 0 problems).
+>
 > **Snapshot: 2026-11-13 ~11:10 (SESSION 157 continued; HEAD `436cbf9d` ==
 > `vgpu/master`; working tree carries one in-flight kernel file
 > (`M kernel/gsp_sema_service.c`, eng20 experiment); supersedes the
@@ -812,11 +871,12 @@ no forcing) -> **M-GL5/M-GL6** (two VMs; video) - with gate definitions in
 The current position is between M-GL1 and M-GL2: the display and GL stacks
 now execute in the guest (NvKms registers, `/dev/dri`, X settles, `glxinfo`
 4.6.0 direct, GZDoom obtains a real GL context), the off-screen GPU frame
-path and the X/DDX stability walls are proven/closed, and captured GL sections
-execute on the engine; the remaining gate is registration of the direct-GL
-payload user/UVM VAS (setup/draw pushes still resolve to zero/implausible
-PAs) plus the window/screen present before a rendered frame (see the snapshot
-above). Both objectives are needed
+path and the X/DDX stability walls are proven/closed, the direct-GL
+submission is fully decoded (macro-driven), and the client's draw-state push
+opens, captures and reaches the engine; the remaining gate is MME macro
+completion (multi-part keep-window A/B pending) plus the window/screen
+present before a rendered frame, with the X first-generation start lottery as
+the throughput limiter (see the snapshot above). Both objectives are needed
 for the 1.0 mission; the CUDA front is backgrounded while the graphics
 campaign holds the device.