wiki: 2026-11-10 status refresh - guest GL draws execute on the physical GPU

Refresh STATE-CURRENT, the Main Page and the status/frontier pages: the GSP
event-IRQ fix completes swaps; the 2D path is green end-to-end; the guest's
real GL draws now forward and execute on the physical GPU (work_gr
backend_ok=9); the draw writes 0 pages because its constant-buffer (MVP)
page is unresolved and forced to the seed page; the MME front-end defer, GR
stale-wedge and the X DDX get-word/notifier completion remain. Published to
open-iov.org.

1 files changed, 6 insertions, 7 deletions

diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md
index e61d307..4ebf765 100644
--- a/wiki/Project-Status.md
+++ b/wiki/Project-Status.md
@@ -10,7 +10,7 @@
 > (the execution frontier). When this page and the docs disagree, the docs tree
 > wins.
 
-Status: 2026-11-09, tree `master @ 21e0d611`. Tags: `[live]` proven with the
+Status: 2026-11-09, tree `master @ cb8e822b`. Tags: `[live]` proven with the
 stock guest driver; `[gated]` implemented, default-off or behind supervised
 gates; `[wip]` partially implemented; `[wall]` current blocker; `[target]`
 named success state; `[planned]` designed, not built.
@@ -28,7 +28,7 @@ named success state; `[planned]` designed, not built.
 | Physical backend on real hardware (module-owned GPU running its real GSP-RM) | `[live]` boot, RPC session, object creation, copy-engine work and GR execution proven — the verified guest CUDA kernel clients execute through this backend, and graphics method streams execute on the engine ([`Graphics-Execution.md`](Graphics-Execution.md)) |
 | Display and KMS on the emulated vGPU (nvidia-modeset/NvKms, `/dev/dri`, X) | `[live]` in the campaign configuration — the emulated display engine serves the guest's display push-buffer channels (notifier plus `UPDATE -> FINISHED`), nvidia-modeset/NvKms registers (`/dev/dri/card0`, `renderD128`, `fb0`), `nvidia-smi -L` enumerates and X settles; the display-capability seam is parameterised ([`Graphics-Execution.md`](Graphics-Execution.md)) |
 | Multi-tenant isolation (mdev per VM, per-context page directories) | `[wip]` device-level coexistence works — multiple mediated devices with different emulated VRAM sizes and multiple guests coexist (two guests demonstrated); per-guest execution isolation for simultaneous CUDA guests is in progress |
-| OpenGL (3D graphics) | `[wip]` — the display/KMS stack registers and X settles; `glxinfo` reports OpenGL 4.6.0 with direct rendering; with GLX forced (`SDL_VIDEO_X11_FORCE_EGL=0`) the windowed GL path uses `libnvidia-glcore`, and the direct GL client's GR and CE channels submit. **No rendered pixels through the emulated vGPU yet:** the minimal `glxgears` hangs in the glcore kick wait (the client polls the per-slot `/dev/nvidia-modeset` fd; the host completes the beef notifier memory but the guest kernel never signals the event), the X DDX get-word/notifier recycle is not implemented, the DDX's 4 GB sysmem allocation forces a 12 GB guest, and the direct-GL draws still report `forwarded=0` ([`OpenGL.md`](OpenGL.md)) |
+| OpenGL (3D graphics) | `[wip]` — the display/KMS stack registers, X settles and `glxinfo` reports OpenGL 4.6.0 with direct rendering; the GSP event-IRQ fix completes swaps, the 2D path is green end-to-end, and the guest's **real GL draws now forward and execute on the physical GPU** (`work_gr backend_ok=9`; glxgears swaps, black). **No rendered pixels through the emulated vGPU yet:** the draw writes 0 pages because its constant-buffer (MVP) page is unresolved/zero and is forced to the seed page; the MME front-end defer, GR stale-wedge, X DDX get-word/notifier completion and the DDX's 4 GB sysmem allocation (12 GB guest) are the remaining walls ([`OpenGL.md`](OpenGL.md)) |
 | Vulkan (3D/compute) | `[wip]` — the guest Vulkan pipeline runs end to end on the emulated vGPU (device, allocation, pipeline, command buffer, fence, queue submit, readback) and the engine executes translated launches; frames are still black — program delivery and program-VA mapping are the frontier ([`Vulkan.md`](Vulkan.md)) |
 | DirectX / Windows guests | `[planned]` (target) — no Windows guest booted yet; the architecture is the same emulation target ([`DirectX.md`](DirectX.md)) |
 | Video (NVENC/NVDEC) | `[planned]` |
@@ -66,7 +66,7 @@ The project's definition of done for CUDA requires all of the following
 Until every gate holds, the honest formulation is: **initialization, the
 driver-API path and kernel execution on the physical GPU work and verify;
 the staged-transfer class, per-guest isolation and the graphics
-present-completion/DDX/first-frame frontier remain.**
+MVP-content/present/first-frame frontier remain.**
 
 ## 3. How to see it yourself
 
@@ -76,10 +76,9 @@ outcome is exactly the ladder above — driver probe, `nvidia-smi`, the full
 driver-API smoke, and guest CUDA kernels executing and verifying on the
 physical GPU. On the graphics side the same setup brings up the display/KMS
 stack and the X server on the emulated vGPU (`glxinfo` reports OpenGL 4.6.0
-with direct rendering); forcing GLX (`SDL_VIDEO_X11_FORCE_EGL=0`) selects
-`libnvidia-glcore`, but the minimal windowed `glxgears` hangs in the glcore
-kick wait and the DDX completion is not yet authored, so kernel-visible
-completion is the frontier ([`OpenGL.md`](OpenGL.md)). The
+with direct rendering); the guest's GL draws execute on the physical GPU and
+glxgears completes swaps, but the constant-buffer (MVP) page does not resolve,
+so the frames are black ([`OpenGL.md`](OpenGL.md)). The
 risc-v-gsp-rm-debugger workbench
 ([`Riscv-GSP-RM-Debugger.md`](Riscv-GSP-RM-Debugger.md)) is the host-side
 tooling used to study the firmware side of that frontier.