docs: 2026-11-12 status refresh - green X/GLX, non-black GPU captures, direct-GL stream frontier

Refresh STATE-CURRENT.md and the open-iov.org wiki pages with the 2026-11-12
state: stock-driver X + GLX green (glxinfo 4.6.0 direct rendering, glxgears
~520 FPS), the pbuffer frame path captured 500/500 non-black frames (50 s
640x480 h264) plus the earlier 45.4 s capture, and the named frontier
(direct-GL client command-stream delivery: setup push unreadable, CE ring
0xbeef0101 intermittent) alongside the guest-init/sizing fixes (RMInstLoc
modprobe single-source, FB info in KB, 256 MiB GART).

1 files changed, 29 insertions, 26 deletions

diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md
index fc076f1..f5bfa9d 100644
--- a/wiki/Execution-Frontier.md
+++ b/wiki/Execution-Frontier.md
@@ -14,7 +14,7 @@
 > [`../docs/04-implementation/03-execution-frontier.md`](../docs/04-implementation/03-execution-frontier.md);
 > the docs tree wins on disagreement.
 
-Status: 2026-11-11, tree `master @ 4acac093`.
+Status: 2026-11-12, tree `master @ 800c108f`.
 Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories
 are labelled as such.
 
@@ -97,20 +97,20 @@ breadth and hardening around it:
 Graphics execution shares this page's submission and completion machinery but
 runs a different engine workload. The display and GL stacks now run end to
 end in the guest: the emulated display engine serves the modeset push buffers,
-nvidia-modeset/NvKms registers (`/dev/dri`), X settles, `glxinfo` reports
-OpenGL 4.6.0 with direct rendering, and the X DDX waits are fixed
-(class-aware display arm, `0x8000 -> 0` notification completion, decoded GL
-release applied); the direct GL client's GR and CE channels submit and retire,
-and the X DDX kick channel is decoded. The **first non-black GPU-rendered
-output** landed: a pbuffer probe returns `pixel=ff0000ff`, the off-screen
-path produced 500/500 animated 640x480 frames, and a 45.4 s video was
-captured. The direct-GL **GR ring `0xbeef0100` now resolves** and its releases
-advance; GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context
-whenever the shared nvClip `modeNum` is even. What is missing is **window/
-screen pixels through the NVIDIA path**: glxgears' window is black, the
-direct-GL **CE ring `0xbeef0101` never resolves** (the guest wedges ~90 s
-after `V_Init`), and X window creation wedges on some boots. The guest Vulkan
-pipeline's inline-to-memory upload arm is its gap. The full picture lives on
+nvidia-modeset/NvKms registers (`/dev/dri`), X settles, and the stock NVIDIA
+GLX path is fully green (`glxinfo -B` returns 0 with OpenGL 4.6.0 and direct
+rendering; `glxgears` renders ~520 FPS). The X DDX waits are fixed and its 3D
+replay executes; the **first non-black GPU-rendered output** landed: a
+pbuffer probe returns `pixel=ff0000ff`, the off-screen path produced 500/500
+non-black 640x480 frames per run and captured videos (45.4 s on 2026-11-11, a
+50 s capture on 2026-11-12), and GZDoom reaches `V_Init: allocate screen`
+with its GL 4.6.0 context when the shared nvClip `modeNum` is even. What is
+missing is **window/screen pixels through the NVIDIA path**: the direct-GL
+client's own 59,556-byte setup push is not yet resolvable/readable host-side
+under the client's page-directory churn, so its draw sections never reach the
+engine, glxgears' window is black, and a synchronous window draw wedges X on
+some boots. The guest Vulkan pipeline's inline-to-memory upload arm is its
+gap. The full picture lives on
 [`Graphics-Execution.md`](Graphics-Execution.md).
 
 No breadth beyond these is claimed: Windows guests, migration and performance
@@ -168,13 +168,15 @@ different emulated VRAM sizes and multiple guests coexist at the device level
 CUDA guests is in progress.
 
 **Issue D — the graphics pixel frontier.** The display/KMS stack and the GL
-client now run end to end (NvKms registers, X settles, GL 4.6, the DDX 3D
-replay executes, the first non-black GPU-rendered frames and a 45.4 s video
-are captured off-screen, and the direct-GL GR ring resolves with advancing
-releases); but the direct-GL CE ring `0xbeef0101` does not resolve, a
-window draw wedges X and glxgears' window is black, and no non-black window/
-screen frame has been produced. The CE ring, the window/screen present and X
-stability are the named blockers
+client now run end to end (NvKms registers, X settles, the stock GLX path is
+fully green with glxinfo 4.6.0 and ~520 FPS glxgears, the DDX 3D replay
+executes, the first non-black GPU-rendered frames and videos are captured
+off-screen, and the direct-GL ring/USERD machinery is substantially hardened);
+but the direct-GL client's 59,556-byte setup push is not yet readable/
+resolvable host-side under its page-directory churn, so its draw sections
+never open on the engine, glxgears' window is black, and a window draw wedges
+X on some boots. Command-stream delivery, the window/screen present and X
+screen-init stability are the named blockers
 ([`Graphics-Execution.md`](Graphics-Execution.md)).
 
 ## 6. Lines of investigation (live)
@@ -189,10 +191,11 @@ stability are the named blockers
 4. **Hold the acceptance battery** — vector-add, matrix-multiply and the
    transformer kernel; each entry is accepted only on its own verification
    output (`bad=0` + `STATUS OK`).
-5. **The graphics pixel frontier** — resolve the direct-GL CE ring
-   `0xbeef0101`, make the window/screen present land, and stabilise X across
-   boots so the proven off-screen frames become window pixels; the lanes, the
-   walls and the milestone ladder are on
+5. **The graphics pixel frontier** — make the direct-GL client's command
+   stream (the 59,556-byte setup push and its ring/CE siblings) resolve and
+   execute host-side, make the window/screen present land, and stabilise X
+   screen-init across boots so the proven off-screen frames become window
+   pixels; the lanes, the walls and the milestone ladder are on
    [`Graphics-Execution.md`](Graphics-Execution.md).
 
 ## 7. Theories, resolved