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, 12 insertions, 11 deletions

diff --git a/wiki/Project-Plan.md b/wiki/Project-Plan.md
index 583264a..459dc59 100644
--- a/wiki/Project-Plan.md
+++ b/wiki/Project-Plan.md
@@ -15,7 +15,7 @@
 > [`../docs/06-portability/03-device-validation-and-porting-sequence.md`](../docs/06-portability/03-device-validation-and-porting-sequence.md);
 > the docs tree wins on disagreement.
 
-Status: 2026-11-09, tree `master @ e342bd0f`. Tags: `[done]`, `[active]`,
+Status: 2026-11-09, tree `master @ 21e0d611`. Tags: `[done]`, `[active]`,
 `[ahead]` — the plan's own state vocabulary, distinct from the goal tags.
 
 ## 1. How the plan works
@@ -44,7 +44,7 @@ itself:
 |---|---|---|---|
 | **P0 — Platform** | Emulated vGPU device, GSP boot and GSP-RM emulation, stock guest driver initialisation | Driver-API smoke green (`ALL OK`) = evaluation rung 2 | `[done]` |
 | **P1 — First execution (compute)** | Guest CUDA kernels executing on the physical GPU, with engine-authored completions; then hardening | Verified clients + engine-authored completion = rung 3 core; hardening: staged-transfer class, every-boot acceptance, per-guest isolation | `[active]` — execution green; hardening in progress |
-| **P2 — Graphics execution** | OpenGL/Vulkan draw commands executed by the physical 3D pipeline and delivered as readable pixels | The graphics ladder: M-GL1 client context-init executes; M-GL2 `glxgears` non-black; M-GL3 GZDoom GL non-black through the mdev | `[active]` — between M-GL1 and M-GL2; the display/KMS and direct-GL channel work is live; the NVIDIA renderer path, the DDX get-word/notifier completion and physical dispatch of the GL draws are the walls |
+| **P2 — Graphics execution** | OpenGL/Vulkan draw commands executed by the physical 3D pipeline and delivered as readable pixels | The graphics ladder: M-GL1 client context-init executes; M-GL2 `glxgears` non-black; M-GL3 GZDoom GL non-black through the mdev | `[active]` — between M-GL1 and M-GL2; the display/KMS and direct-GL channel work is live; kernel-visible GL present completion, the DDX get-word/notifier completion and physical dispatch of the GL draws are the walls |
 | **P3 — Sustained and multi-tenant** | Frame rates without assistance; multiple VMs sharing the GPU with measured fairness; soak-stable operation | Graphics M-GL4 (60 fps, no forcing) and M-GL5 (two VMs, two mdevs); CUDA battery + soak; per-guest execution isolation = rungs 4/5 | `[ahead]` |
 | **P4 — Breadth** | Video (NVENC/NVDEC), Windows/DirectX guests, live migration, non-KVM hypervisor transports | Per-case bring-up gates plus the matrix's evidence expectations | `[ahead]` |
 | **P5 — Scale and portability** | New GPU generations and driver families carried forward; published performance programme | A profile + measured delta per version, validated on hardware; A/B numbers published per the measurement contract | `[ahead]` |
@@ -57,11 +57,12 @@ available (P5 runs across the whole plan).
 
 Ranked, in dependency order:
 
-1. **Graphics pixels (P2).** The client and display stacks execute; the
-   named walls are the NVIDIA renderer path (Vulkan ICD device creation or
-   forced GLX), the X DDX push-buffer get-word/notifier completion, the DDX's
-   4 GB sysmem allocation (12 GB guest workaround), physical dispatch of the
-   GL draws (`forwarded=0`), then non-black frames. Full detail:
+1. **Graphics pixels (P2).** The client and display stacks execute, and
+   forcing GLX selects `libnvidia-glcore`; the named walls are the
+   kernel-visible GL present/kick completion (minimal `glxgears` hangs in it),
+   the X DDX push-buffer get-word/notifier completion, the DDX's 4 GB sysmem
+   allocation (12 GB guest workaround), physical dispatch of the GL draws
+   (`forwarded=0`), then non-black frames. Full detail:
    [`Graphics-Execution.md`](Graphics-Execution.md) §6.
 2. **Compute hardening (P1).** The staged-transfer class (failure modes proven,
    fixes in flight); the every-boot acceptance campaign; per-guest execution
@@ -78,10 +79,10 @@ post-reboot client-stall defect (compute reproducibility); the display/KMS
 bring-up (NvKms registers, X settles, GL 4.6); the UVM channel-pool tracker;
 the direct-GL GR release and CE ring discovery; the X DDX kick-channel decode
 and its three wait fixes (class-aware display arm, `0x8000 -> 0` notification
-completion, decoded GL release applied); GZDoom reaching renderer startup and
-`MAP01` once the DDX push-buffer loop was unblocked (currently on Mesa
-llvmpipe, not the emulated vGPU); and the guest Vulkan pipeline running end to
-end.
+completion, decoded GL release applied); forced GLX selecting `libnvidia-glcore`
+(the EGL/Mesa fallback is gone); GZDoom reaching renderer startup and `MAP01`
+once the DDX push-buffer loop was unblocked (a Mesa llvmpipe datapoint); and
+the guest Vulkan pipeline running end to end.
 
 ## 4. The gates