wiki: 2026-11-09 evening refresh 2 - forced GLX reaches glcore; windowed GL waits on kernel kick completion

Refresh STATE-CURRENT, the Main Page and the status/frontier pages: with
SDL_VIDEO_X11_FORCE_EGL=0 the windowed GL path selects libnvidia-glcore,
but the minimal glxgears hangs in the glcore kick wait (poll on the
per-slot /dev/nvidia-modeset fd) while the host completes the beef
notifier memory. The X DDX get-word/notifier completion, the DDX 4 GB
sysmem footprint and physical dispatch of the GL draws remain. Published
to open-iov.org.

1 files changed, 15 insertions, 10 deletions

diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md
index 57ede35..658f222 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 @ e342bd0f`.
+Status: 2026-11-09, tree `master @ 21e0d611`.
 Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories
 are labelled as such.
 
@@ -103,10 +103,13 @@ 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 renderer
-backend (Vulkan ICD device creation or forced GLX), the DDX get-word/notifier
-completion and physical dispatch of the GL draws are the named walls, and the
-guest Vulkan pipeline's inline-to-memory upload arm remains its gap. The full
+What is missing is **rendered pixels through the NVIDIA path**: forcing GLX
+now selects `libnvidia-glcore`, but the minimal windowed `glxgears` hangs in
+the glcore kick wait (the client polls its per-slot `/dev/nvidia-modeset` fd
+and the guest kernel never signals the event), the DDX push-buffer
+get-word/notifier completion is not implemented, and the direct-GL draws still
+report no physical dispatch; the guest Vulkan pipeline's inline-to-memory
+upload arm remains its gap. The full
 picture lives on [`Graphics-Execution.md`](Graphics-Execution.md).
 
 No breadth beyond these is claimed: Windows guests, migration and performance
@@ -165,11 +168,13 @@ 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), but no rendered
-(non-black) frame has been produced yet through the NVIDIA path; GZDoom's
-`MAP01` is a Mesa llvmpipe datapoint. The renderer backend (Vulkan ICD or
-forced GLX), the DDX get-word/notifier completion and physical dispatch of
-the GL draws (`forwarded=0`) are the named blockers
+channels submit and retire, the X DDX waits are fixed), and forcing GLX
+selects `libnvidia-glcore`; but the minimal windowed `glxgears` hangs in the
+glcore kick wait (the client polls its per-slot `/dev/nvidia-modeset` fd and
+the guest kernel never signals the event), and no rendered (non-black) frame
+has been produced yet. The kernel-visible present completion, the DDX
+get-word/notifier completion and physical dispatch of the GL draws
+(`forwarded=0`) are the named blockers
 ([`Graphics-Execution.md`](Graphics-Execution.md)).
 
 ## 6. Lines of investigation (live)