wiki: 2026-11-10 afternoon refresh - first real GPU readback; direct-GL/window walls

Refresh STATE-CURRENT, the Main Page and the status/frontier pages: the DDX
3D replay executes and a guest pbuffer glClear+glReadPixels returns a red
pixel (ff0000ff); the RM write-lock holder (Xorg in the DDX scrub wait) is
fixed in df6e71bb. The direct-GL client channel still emits only setup/notify
kicks (ops_runs=0), a window draw wedges X, and X startup/RM stability plus
the DDX 4 GB sysmem allocation remain. Published to open-iov.org.

1 files changed, 12 insertions, 13 deletions

diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md
index d90fdd7..2dd70ae 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-09, tree `master @ bb802909`.
+Status: 2026-11-09, tree `master @ df6e71bb`.
 Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories
 are labelled as such.
 
@@ -103,11 +103,11 @@ OpenGL 4.6.0 with direct rendering, and the X DDX waits are fixed
 release applied); the direct GL client's GR and CE channels submit and retire,
 and the X DDX kick channel is decoded. GZDoom reached `MAP01` once the DDX
 push-buffer loop was unblocked, but on Mesa llvmpipe — not the emulated vGPU.
-What is missing is **rendered pixels through the NVIDIA path**: the GSP
-event-IRQ fix completes swaps, the 2D path is green end-to-end, X is reliable,
-and the guest's real GL draws forward and execute on the physical GPU, but the
-draw writes 0 pages. The beef GR ring resolution race, the fixed-CB image's
-zero `0x80` MVP block and the render-target bind are the named walls. The
+What is missing is **screen pixels through the NVIDIA path**: the 2D path is
+green, the DDX 3D replay executes, and the first real GPU readback landed
+(pbuffer `pixel=ff0000ff`), but the direct-GL client still emits only
+setup/notify kicks (`ops_runs=0`) and a synchronous window draw wedges X. The
+direct-GL draw capture and the window/screen present are the named walls. The
 guest Vulkan pipeline's inline-to-memory upload arm is its gap. The full
 picture lives on [`Graphics-Execution.md`](Graphics-Execution.md).
 
@@ -166,13 +166,12 @@ 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, direct-GL
-channels submit and retire, the X DDX waits are fixed, X is reliable, and the
-guest's real GL draws forward and execute on the physical GPU); but the draw
-writes 0 pages and no rendered (non-black) frame has been produced yet. The
-beef GR ring resolution, the fixed-CB image's zero MVP block and the
-render-target bind are the named blockers
-([`Graphics-Execution.md`](Graphics-Execution.md)).
+client now run end to end (NvKms registers, X settles, GL 4.6, the DDX 3D
+replay executes, and the first real GPU readback returns a red pbuffer
+pixel); but the direct-GL client still emits only setup/notify kicks
+(`ops_runs=0`), a window draw wedges X, and no non-black screen frame has
+been produced. The direct-GL draw capture and the window/screen present are
+the named blockers ([`Graphics-Execution.md`](Graphics-Execution.md)).
 
 ## 6. Lines of investigation (live)