wiki: 2026-11-11 status refresh - first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls (STATE-CURRENT too)

13 files changed, 288 insertions, 180 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 7c43dea..5762b4f 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,5 +1,66 @@
 # Open-IOV Current State
 
+> **Snapshot: 2026-11-11 ~10:45 (SESSION 156 continued; HEAD `4acac093` ==
+> `vgpu/master`; working tree carries in-flight kernel work; supersedes the
+> 2026-11-10 ~16:45 entry below).**
+> The **first non-black GPU-rendered GL output and the first captured video**
+> landed on the emulated vGPU. r1764 (`131d44e0`) proved the pbuffer path: the
+> probe returns `PROBE rc=0 err=0x0 pixel=ff0000ff` and the off-screen frame
+> producer published 40/40 animated 640x480 frames rendered on the physical
+> GPU (pbuffer -> sysmem -> kvmfr ivshmem -> host `frame_reader.py`). r1769
+> validated the V6 ring-ledger scrub release (`f6184ac3`): X green 4/4 cycles,
+> zero panics/wedges, `gl_frames 500/500` non-black, 454 PPMs, and a 640x480
+> h264 10 fps 45.4 s video
+> (`backups/evidence-20261002-victory/r1769/vgpu-gl-animation.mp4`). The
+> scrubber release value is the guest's `lastSubmittedWorkId`; the ring ledger
+> counts GPFIFO pushes and advances fin forward-only (never all-ones), so the
+> fin=12 underflow class is closed.
+>
+> Commit `4acac093` (V9/V10) resolves the **direct-GL GR ring `0xbeef0100`**
+> (beef-family always-probe, per-channel promote backoff, rank-collision
+> fallback, parked-candidate eviction). Receipts: `RING-VAS` mapped, RAM scan
+> `va=0x4020000 -> pa=0x1ee8000`, 132 `sema-push`, 101 `sema-sw` releases
+> advancing `0x1 -> 0x27` (39 frames); glxgears 504-516 FPS with no
+> regression; a ~120 s GZDoom run had zero DDX channel-idle timeouts. GZDoom
+> now **passes the VBO wall whenever the shared nvClip `modeNum` is even**:
+> on a fresh X it logs window -> `GL_VERSION 4.6.0` -> 640x480 -> `I_Init` ->
+> `V_Init: allocate screen` with 0 SIGSEGV, and its direct-GL channels
+> register with the GR lane live. The SIGSEGV at `0x20` was root-caused
+> (coredump + LD_PRELOAD shim + host gdb) to `FFlatVertexBuffer::Copy` ->
+> `memcpy(NULL, ..., 640)` because `glMapBufferRange`/`glBufferData` return
+> NULL + `0x505` when the client's `__glNVStateInit` fails the modeswitch
+> test with an odd `modeNum` (live read: wedged X = 3, fresh X = 2). The +1
+> is the guest kernel's nvKms deferred close (the host completes
+> UPDATE -> FINISHED but no control arrives at the +1) - guest-side, not
+> module-induced.
+>
+> **New top wall:** the direct-GL **CE ring `0xbeef0101` (gpfifo=0x4100000)
+> never resolves** - `VAS-PROMOTE cand pdb=0x108eb3000 walk rc=-2` plus
+> `NOT mapped by any registered VAS` every ~7 s - so GZDoom's CE work never
+> executes and the guest wedges ~90 s after `V_Init`. Next: walk all parked
+> candidates regardless of owner VAS and/or keep >=2 fresh same-VAS parks.
+> **Window/screen pixels remain unproven:** glxgears' window is still black
+> (the GLX probe/frames path is a per-window lottery), and X window creation
+> wedges on 3/6 boots in an unkillable Xorg spin (`_nv052600rm+0x7b`); one
+> cycle also saw 2x "Wait for channel idle timed out".
+>
+> Walls ranked: (1) direct-GL CE ring `0xbeef0101` resolution (blocks the
+> GZDoom game loop); (2) window/screen pixels and the GLX per-window lottery;
+> (3) X startup/stability and the VASpace/ScreenInit allocation lottery
+> (`_nv052600rm+0x7b`, `0x51`, vmalloc); (4) the DDX 4 GB sysmem
+> allocation/OOM (12 GB guest); (5) sustained non-black window frames.
+>
+> CUDA front unchanged (backgrounded while graphics holds the device; its
+> 10-30 status stands): `41343c63` green (`victory_mail` `VADD bad=0` +
+> `STATUS OK`; `vecadd_loop` 100 launches PASS); the fresh-boot battery's
+> red class is D2H-stage with release-discipline fixes staged; the SESSION
+> 143 Vulkan fence regression is not re-measured.
+>
+> Live at check (read-only): HEAD `4acac093` == `vgpu/master`; working tree
+> `M kernel/gsp_sema_service.c` (in-flight campaign work); evidence under
+> `backups/evidence-20261002-victory/r1769/`, `r1774/`, `r1775/`; pstore
+> empty; no reboot during the check.
+>
 > **Snapshot: 2026-11-10 ~16:45 (SESSION 156 continued; HEAD `df6e71bb`,
 > tree has in-flight kernel/tool work; supersedes the 06:10 entry below).**
 > The **first real GPU readback** landed: a guest
diff --git a/wiki/.publish-manifest.json b/wiki/.publish-manifest.json
index 74759ce..115467e 100644
--- a/wiki/.publish-manifest.json
+++ b/wiki/.publish-manifest.json
@@ -64,11 +64,11 @@
  },
  "FAQ": {
   "file": "FAQ.wiki",
-  "new_revid": 24097,
-  "old_revid": 24085,
-  "source_sha": "a249bba8af80cd8e",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:40:55Z",
+  "new_revid": 24109,
+  "old_revid": 24097,
+  "source_sha": "cf9501f4109622b6",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:54Z",
   "title": "FAQ"
  },
  "GMMU Multi-Tenant Protection": {
@@ -127,11 +127,11 @@
  },
  "Graphics Execution": {
   "file": "Graphics-Execution.wiki",
-  "new_revid": 24098,
-  "old_revid": 24086,
-  "source_sha": "a6bc3db0939616d9",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:40:56Z",
+  "new_revid": 24110,
+  "old_revid": 24098,
+  "source_sha": "e71a92a67d25eeb2",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:55Z",
   "title": "Graphics Execution"
  },
  "Guest Driver Lifecycle: A Field Guide": {
@@ -226,11 +226,11 @@
  },
  "OpenGL": {
   "file": "OpenGL.wiki",
-  "new_revid": 24100,
-  "old_revid": 24088,
-  "source_sha": "4c5dbee20ce762fe",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:40:57Z",
+  "new_revid": 24112,
+  "old_revid": 24100,
+  "source_sha": "4ba49af3ebb2f1c8",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:56Z",
   "title": "OpenGL"
  },
  "Performance": {
@@ -244,38 +244,38 @@
  },
  "Physical GPU Backend and Guest Wiring": {
   "file": "Physical-GPU-Backend.wiki",
-  "new_revid": 24101,
-  "old_revid": 24089,
-  "source_sha": "f366ffcfd0513e04",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:40:58Z",
+  "new_revid": 24113,
+  "old_revid": 24101,
+  "source_sha": "045d4371c63d7f57",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:56Z",
   "title": "Physical GPU Backend and Guest Wiring"
  },
  "Project Goals": {
   "file": "Project-Goals.wiki",
-  "new_revid": 24102,
-  "old_revid": 24090,
-  "source_sha": "62e47d7d23cb7cc3",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:40:58Z",
+  "new_revid": 24114,
+  "old_revid": 24102,
+  "source_sha": "a1eb9fd7bb6c9282",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:57Z",
   "title": "Project Goals"
  },
  "Project Plan": {
   "file": "Project-Plan.wiki",
-  "new_revid": 24103,
-  "old_revid": 24091,
-  "source_sha": "f771eb3323903178",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:40:59Z",
+  "new_revid": 24115,
+  "old_revid": 24103,
+  "source_sha": "5413cd31633f0781",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:57Z",
   "title": "Project Plan"
  },
  "Project Status": {
   "file": "Project-Status.wiki",
-  "new_revid": 24104,
-  "old_revid": 24092,
-  "source_sha": "ec76c4f58530952c",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:40:59Z",
+  "new_revid": 24116,
+  "old_revid": 24104,
+  "source_sha": "cdbe587f95371ca5",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:58Z",
   "title": "Project Status"
  },
  "RPC Message Format": {
@@ -289,11 +289,11 @@
  },
  "System Overview": {
   "file": "System-Overview.wiki",
-  "new_revid": 24105,
-  "old_revid": 24093,
-  "source_sha": "3317be0a59ba72cd",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:41:00Z",
+  "new_revid": 24117,
+  "old_revid": 24105,
+  "source_sha": "6d4d08fffb5ff6c0",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:58Z",
   "title": "System Overview"
  },
  "Template:About message": {
@@ -325,11 +325,11 @@
  },
  "The Execution Frontier": {
   "file": "Execution-Frontier.wiki",
-  "new_revid": 24095,
-  "old_revid": 24083,
-  "source_sha": "b66f76919923080a",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:40:54Z",
+  "new_revid": 24107,
+  "old_revid": 24095,
+  "source_sha": "0a952f3fe56873b1",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:53Z",
   "title": "The Execution Frontier"
  },
  "The Guest Stack and CUDASW": {
@@ -343,20 +343,20 @@
  },
  "The Host Module (vgsp.ko)": {
   "file": "Host-Module.wiki",
-  "new_revid": 24099,
-  "old_revid": 24087,
-  "source_sha": "24e5342d41ff772c",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:40:56Z",
+  "new_revid": 24111,
+  "old_revid": 24099,
+  "source_sha": "a92d0397166fb875",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:55Z",
   "title": "The Host Module (vgsp.ko)"
  },
  "The vGSP Execution Plane (vEP)": {
   "file": "Execution-Plane.wiki",
-  "new_revid": 24096,
-  "old_revid": 24084,
-  "source_sha": "27898c25eb230b57",
-  "summary": "2026-11-10 afternoon refresh: first real GPU readback (pbuffer red pixel); direct-GL draw capture and window/screen present are the walls",
-  "timestamp": "2026-11-10T21:40:55Z",
+  "new_revid": 24108,
+  "old_revid": 24096,
+  "source_sha": "758b224f3c94f02a",
+  "summary": "2026-11-11 refresh: first non-black GPU frames + 45.4 s video; direct-GL GR ring resolves; CE-ring/window walls",
+  "timestamp": "2026-11-11T15:48:54Z",
   "title": "The vGSP Execution Plane (vEP)"
  },
  "UVM in the Guest": {
diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md
index 2dd70ae..fc076f1 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 @ df6e71bb`.
+Status: 2026-11-11, tree `master @ 4acac093`.
 Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories
 are labelled as such.
 
@@ -101,15 +101,17 @@ 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. GZDoom reached `MAP01` once the DDX
-push-buffer loop was unblocked, but on Mesa llvmpipe — not the emulated vGPU.
-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).
+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
+[`Graphics-Execution.md`](Graphics-Execution.md).
 
 No breadth beyond these is claimed: Windows guests, migration and performance
 numbers remain planned.
@@ -167,11 +169,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, 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)).
+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
+([`Graphics-Execution.md`](Graphics-Execution.md)).
 
 ## 6. Lines of investigation (live)
 
@@ -185,9 +189,10 @@ the named blockers ([`Graphics-Execution.md`](Graphics-Execution.md)).
 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** — materialise the driver's program
-   uploads and map the program VA so draws execute with real state; the lanes,
-   the walls and the milestone ladder are on
+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
    [`Graphics-Execution.md`](Graphics-Execution.md).
 
 ## 7. Theories, resolved
diff --git a/wiki/Execution-Plane.md b/wiki/Execution-Plane.md
index 03a739a..d88a1f3 100644
--- a/wiki/Execution-Plane.md
+++ b/wiki/Execution-Plane.md
@@ -8,7 +8,7 @@
 > when the two disagree, the docs tree wins. Front door:
 > [`../docs/README.md`](../docs/README.md).
 
-Status: 2026-11-09, tree `master @ df6e71bb`. Tags: `[live]` proven with the
+Status: 2026-11-11, tree `master @ 4acac093`. Tags: `[live]` proven with the
 stock guest driver; `[gated]` implemented, default-off or parameter-gated;
 `[wip]` partial; `[wall]` current blocker; `[target]` named success latch;
 `[planned]` designed, not built.
@@ -150,11 +150,13 @@ guest: push + QMD + GPFIFO entry + doorbell (BAR0 0x88704)
   registers, X settles and GL 4.6 is live, the X DDX waits are fixed, and
   the guest's real GL draws now forward and execute on the physical GPU
   (`backend_ok=5-7`, `backend_timeout=0`); the DDX 3D replay executes, the 2D
-  path is green, and the first real GPU readback landed (pbuffer red pixel).
-  No non-black **screen** frame has been produced through the NVIDIA path
-  yet: the direct-GL client emits only setup/notify kicks and a window draw
-  wedges X, so the direct-GL draw capture and the window/screen present are
-  the named blockers. The lanes and the ladder are on
+  path is green, the first non-black GPU-rendered frames are proven (500/500
+  off-screen frames plus a 45.4 s video), and the direct-GL **GR ring
+  `0xbeef0100` resolves with advancing releases**. No non-black **window/
+  screen** frame has been produced through the NVIDIA path yet: the direct-GL
+  **CE ring `0xbeef0101` never resolves** (the guest wedges ~90 s after
+  `V_Init`), glxgears' window is black, and X window creation wedges on some
+  boots, so those are the named blockers. The lanes and the ladder are on
   [`Graphics-Execution.md`](Graphics-Execution.md).
 
 ## 6. Portability
diff --git a/wiki/FAQ.md b/wiki/FAQ.md
index e4361a6..d3e42db 100644
--- a/wiki/FAQ.md
+++ b/wiki/FAQ.md
@@ -5,7 +5,7 @@
 > [`../docs/09-reference/glossary-and-faq.md`](../docs/09-reference/glossary-and-faq.md);
 > the docs tree wins on disagreement.
 
-Status: 2026-11-09, tree `master @ df6e71bb`.
+Status: 2026-11-11, tree `master @ 4acac093`.
 
 ## Project and positioning
 
@@ -38,18 +38,20 @@ progress). This is the project's known status, not a misconfiguration — see
 
 **Can I run OpenGL or Vulkan applications in the guest?**
 Partially, and it is an active frontier. The display/KMS stack and the X
-server now run on the emulated vGPU with the stock driver: nvidia-modeset/NvKms
+server run on the emulated vGPU with the stock driver: nvidia-modeset/NvKms
 registers (`/dev/dri`), `glxinfo` reports OpenGL 4.6.0 with direct rendering,
-the 2D path is green and the DDX 3D replay executes; the **first real GPU
-readback** landed (a pbuffer `glClear(red)+glReadPixels` probe returns
-`pixel=ff0000ff`). The RM write-lock holder (Xorg in the DDX vidheap scrub
-wait) was identified and fixed (`df6e71bb`). The guest Vulkan pipeline runs
-end to end (device → command buffer → fence → readback, frames black). Screen
-pixels are still the wall: the direct-GL client channel `0xbfef0002` emits
-only setup/notify kicks (`ops_runs=0`), a synchronous window draw wedges X,
-and X startup/RM degradation (`0x51`) plus the DDX's 4 GB sysmem allocation
-(12 GB guest workaround) remain — see [`OpenGL.md`](OpenGL.md),
-[`Vulkan.md`](Vulkan.md) and [`Graphics-Execution.md`](Graphics-Execution.md).
+the 2D path is green and the DDX 3D replay executes. The **first non-black
+GPU-rendered output** is proven: a pbuffer probe returns `pixel=ff0000ff`, the
+off-screen path produced 500/500 non-black animated frames, and a 45.4 s video
+was captured. The direct-GL GR channel now submits and its releases advance;
+GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context. Window and
+screen pixels are still the wall: glxgears' window is black, the direct-GL CE
+channel does not yet resolve (GZDoom wedges ~90 s after `V_Init`), X window
+creation wedges on some boots, and the DDX's 4 GB sysmem allocation forces a
+12 GB guest. The guest Vulkan pipeline runs end to end (device → command
+buffer → fence → readback) but frames are black. See
+[`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) and
+[`Graphics-Execution.md`](Graphics-Execution.md).
 
 **How fast is it?**
 No published numbers yet. Kernel launches execute on the physical engine;
diff --git a/wiki/Graphics-Execution.md b/wiki/Graphics-Execution.md
index 1cdb15f..7d67836 100644
--- a/wiki/Graphics-Execution.md
+++ b/wiki/Graphics-Execution.md
@@ -12,7 +12,7 @@
 > [`../docs/04-implementation/04-real-render-walls.md`](../docs/04-implementation/04-real-render-walls.md)
 > (the measured walls); the docs tree wins on disagreement.
 
-Status: 2026-11-09, tree `master @ df6e71bb`. Tags: `[live]` observed end to
+Status: 2026-11-11, tree `master @ 4acac093`. Tags: `[live]` observed end to
 end; `[wip]` partially built; `[wall]` current blocker; `[target]` defined
 success state; `[planned]` designed, not built.
 
@@ -86,11 +86,15 @@ fidelity:
    `0x1000014` executes its 3D replay (12 launches per cycle), the 2D path is
    green, and a guest pbuffer `glClear(red)+glFinish+glReadPixels` probe
    returns a real pixel (`pixel=ff0000ff`): the replay and readback machinery
-   works. The direct-GL client's own channel (`0xbfef0002` this cycle) opens
-   a C597 section but emits only 32/64-byte setup/notify kicks
-   (`ops_runs=0`), so its draws never reach the host; a synchronous window
-   draw also wedges X. That draw submission and the window/screen present are
-   what remains (§6).
+   works. The off-screen frame path then produced **500/500 non-black 640x480
+   animated frames** and a captured 45.4 s video. The direct-GL **GR ring
+   `0xbeef0100` now resolves** (`4acac093`: beef-family always-probe,
+   per-channel promote backoff, rank-collision fallback, parked-candidate
+   eviction); its releases advance frame by frame and GZDoom reaches
+   `V_Init: allocate screen` with its GL 4.6.0 context. The direct-GL **CE
+   ring `0xbeef0101` never resolves**, so the client's CE work does not
+   execute and the guest wedges ~90 s after `V_Init`; window/screen present
+   is still the frontier (§6).
 
 ## 4. The channel and object picture
 
@@ -142,9 +146,11 @@ event-IRQ fix now sets the RISC-V SWGEN0 IRQSTAT/IRQMASK/IRQDEST and latches
 the CPU-tree leaf, so the guest services the event and glxgears completes
 swaps, and the GR backend no longer times out (the pair-close/pair-safe
 replay fixes are default ON; draws retire in 3-2400 ms). The DDX 3D replay
-now renders and reads back a pbuffer pixel (`pixel=ff0000ff`), and the
-RM write-lock holder (Xorg in the DDX vidheap scrub wait) is fixed. The next
-step is the direct-GL client's draw submission/capture and the window/screen
+renders and reads back a pbuffer pixel (`pixel=ff0000ff`), the off-screen
+frame path produced non-black animated frames and a 45.4 s video, the
+RM write-lock holder (Xorg in the DDX vidheap scrub wait) is fixed
+(`df6e71bb`), and the direct-GL GR ring now resolves with advancing releases.
+The next step is the direct-GL CE ring `0xbeef0101` and the window/screen
 present path.
 
 During bring-up the module also carries a **diagnostics-only mirror** for apps
@@ -154,27 +160,35 @@ requires it switched off, along with any external poke.
 
 ## 6. Where the frontier is (ranked walls)
 
-1. **Direct-GL draw submission/capture** `[wall]`. The GL client channel
-   `0xbfef0002` opens a C597 section but emits only 32/64-byte setup/notify
-   kicks (`ops_runs=0`; `section captured` and `GR LAUNCH` are 0). The DDX
-   channel `0x1000014` works (12 launches/cycle), so the gap is the
-   direct-GL client's submit path, not the replay machinery.
-2. **Window/screen present and X stability** `[wall]`. A synchronous window
-   GL draw wedges X (`xwd -root` writes 0 bytes; `XGetImage` never
-   completes), while the pbuffer probe works. Screen capture must use the
-   ivshmem frame path, and the X must survive the draw.
-3. **X startup / RM degradation** `[wall]`. X startup is a lottery
-   (`Failed to initialize DMA`, push-buffer `0x51`, occasional vmalloc
-   96 GB), and X can die after forward activity; a fresh cycle clears it.
+1. **Direct-GL CE ring resolution** `[wall]`. The GR ring `0xbeef0100`
+   resolves and its releases advance, but the CE ring `0xbeef0101`
+   (`gpfifo=0x4100000`) never maps: `VAS-PROMOTE` walks a parked candidate and
+   returns `rc=-2`, then `NOT mapped by any registered VAS` every ~7 s. The
+   client's CE work never executes and GZDoom wedges ~90 s after `V_Init`.
+   Next: walk all parked candidates regardless of owner VAS and/or keep at
+   least two fresh same-VAS parks.
+2. **Window/screen present and the GLX lottery** `[wall]`. The pbuffer and
+   off-screen frame paths are proven (`pixel=ff0000ff`, 500/500 non-black
+   frames, 45.4 s video), but glxgears' window is black and the GLX
+   probe/frames path is a per-window lottery (hang/black/BadValue). A
+   synchronous window draw wedges X; screen capture must use the ivshmem
+   frame path and the present must be made to land.
+3. **X startup / stability** `[wall]`. X startup is a per-boot lottery: on
+   3/6 boots window creation wedges Xorg in an unkillable kernel RM spin
+   (`_nv052600rm+0x7b`); `Failed to initialize DMA`, push-buffer `0x51`,
+   `Wait for channel idle timed out` and occasional vmalloc failures also
+   appear. A fresh cycle clears it. The shared nvClip `modeNum` must be even
+   for the GL client's state init to succeed; the odd value is the guest
+   kernel's nvKms deferred close, not module-induced.
 4. **The X DDX footprint** `[wall]`. The DDX allocates 4 GB of system pages at
    startup; an 8 GB guest has no headroom once GZDoom's own footprint lands
    and both are OOM-killed. Current runs use a 12 GB guest; the allocation is
    a suspected emulation gap (a 512 MiB emulated VRAM falling back to a 4 GB
    sysmem allocation) to fix.
-5. **Non-black screen frames and sustained rate** `[wall]`/`[target]`. Once
-   the direct-GL draw capture and the window/screen present land, the capture
-   must show motion, then 60 fps in one VM with no forcing, then two VMs on
-   two mediated devices with non-black frames in both.
+5. **Non-black window frames and sustained rate** `[wall]`/`[target]`. Once
+   the CE ring, the window/screen present and X stability land, the capture
+   must show motion in a window, then 60 fps in one VM with no forcing, then
+   two VMs on two mediated devices with non-black frames in both.
 
 ## 7. What is proven today
 
@@ -191,25 +205,31 @@ requires it switched off, along with any external poke.
 | GR backend timeouts fixed (`backend_timeout=0`; draws retire in 3-2400 ms) | `[live]` |
 | DDX 3D replay executes (`section captured` + `GR LAUNCH` on `0x1000014`, 12 launches/cycle) | `[live]` |
 | First real GPU readback: pbuffer `glClear(red)+glReadPixels` -> `pixel=ff0000ff` | `[live]` |
+| First non-black GPU-rendered frames: 500/500 off-screen frames; 45.4 s video captured (`r1769`) | `[live]` |
+| Direct-GL GR ring `0xbeef0100` resolves; releases advance (`4acac093`) | `[live]` |
+| GZDoom passes `V_Init: allocate screen` with GL 4.6.0 when shared nvClip `modeNum` is even | `[live]` |
 | RM write-lock holder identified (Xorg in the DDX vidheap scrub wait) and fixed (`df6e71bb`) | `[live]` |
 | GL section capture: the X channel's `0xC597` stream decoded | `[live]` |
 | Verbatim 3D method-stream replay retired by the engine (no MMU fault) | `[live]` |
 | Synthesized launch executes real `sm_75` SASS; Turing `V3` program header accepted | `[live]` |
 | X server survives the run on a 12 GB guest (the DDX's 4 GB sysmem allocation forces the size) | `[live]` |
-| Direct-GL channel `0xbfef0002` submits a captured draw (`ops_runs>0`) | `[wall]` |
-| Window/screen present completes without wedging X (ivshmem frame path) | `[wall]` |
-| X startup/RM stability (`0x51`, vmalloc 96 GB) | `[wall]` |
-| NVIDIA Vulkan ICD creates a device | `[wall]` |
+| Direct-GL CE ring `0xbeef0101` resolves and the client's CE work executes | `[wall]` |
+| Window/screen present produces non-black window pixels | `[wall]` |
+| X startup/stability (`_nv052600rm` soft-lock, `0x51`, vmalloc) | `[wall]` |
 | Non-black screen pixels from the emulated vGPU's 3D pipeline | `[wall]` |
 | Windows/DirectX guests | `[planned]` |
 
 ## 8. What is not claimed
 
-* No non-black pixel has been produced by the emulated vGPU's 3D pipeline yet.
+* No **window/screen** pixel has been produced by the emulated vGPU's 3D
+  pipeline yet; every screen capture so far is black. The proven non-black
+  frames and the 45.4 s video come from the off-screen pbuffer path
+  (pbuffer -> sysmem -> kvmfr ivshmem -> host reader), not from a windowed X
+  screen capture.
 * Display/KMS bring-up (NvKms, `/dev/dri`, X, a real GL context) is not a
-  rendered-frame claim. The first readback pixel is a pbuffer probe, not a
-  window/screen frame; the direct-GL client still emits only setup/notify
-  kicks, and a window draw wedges X. Those are the current walls.
+  rendered-frame claim. GZDoom reaching `V_Init: allocate screen` proves the
+  client's GL init and the direct-GL GR lane, not the game loop or a
+  presented frame; the direct-GL CE ring still does not resolve.
 * No frame-rate or latency numbers: the scheduled measurement is defined
   (60 fps over 60 s, no forcing) but not yet met.
 * The `virgl`-based demo videos are a different, labelled path — not this one.
diff --git a/wiki/Host-Module.md b/wiki/Host-Module.md
index b1fd6a1..6ffbed1 100644
--- a/wiki/Host-Module.md
+++ b/wiki/Host-Module.md
@@ -6,7 +6,7 @@
 > source: [`../docs/03-architecture/06-host-module-and-hybrid-model.md`](../docs/03-architecture/06-host-module-and-hybrid-model.md);
 > the docs tree wins on disagreement with this page.
 >
-> Status: 2026-11-09, tree `master @ df6e71bb`. Tags: `[live]` observed with
+> Status: 2026-11-11, tree `master @ 4acac093`. Tags: `[live]` observed with
 > the stock guest driver; `[wip]` demonstrated live, being productized;
 > `[gated]` implemented default-off behind supervised gates; `[wall]` known
 > blocking limit; `[target]` designed, not built; `[planned]` roadmap.
@@ -125,11 +125,14 @@ nvidia-modeset/NvKms register (`/dev/dri`), X settle and GLX clients obtain a
 real GL context. The display-capability seam is parameterised. For the DDX's
 own 2D push buffers the remaining host levers are publishing/advancing the
 GPU-written engine get word and recycling the notifier to `0xffff` after
-completion. The DDX 3D replay now renders and reads back a pbuffer pixel
-(`pixel=ff0000ff`), and the RM write-lock holder (Xorg in the DDX vidheap
-scrub wait) is fixed (`df6e71bb`). The remaining GL gap is the direct-GL
-client's draw submission/capture (`0xbfef0002` still emits only setup/notify
-kicks) and the window/screen present path, which currently wedges X.
+completion. The DDX 3D replay renders and reads back a pbuffer pixel
+(`pixel=ff0000ff`), the off-screen frame path produced 500/500 non-black
+animated frames and a 45.4 s video, the RM write-lock holder (Xorg in the
+DDX vidheap scrub wait) is fixed (`df6e71bb`), and the direct-GL GR ring
+`0xbeef0100` now resolves with advancing releases (`4acac093`). The remaining
+GL gap is the direct-GL CE ring `0xbeef0101` (it never resolves, so the
+client's CE work does not execute) and the window/screen present path, which
+currently wedges X or stays black.
 
 ## 6. Debug parameters
 
diff --git a/wiki/OpenGL.md b/wiki/OpenGL.md
index 7445d12..d09b1e9 100644
--- a/wiki/OpenGL.md
+++ b/wiki/OpenGL.md
@@ -12,7 +12,7 @@
 > [`../docs/03-architecture/02-guest-stack-and-cudasw.md`](../docs/03-architecture/02-guest-stack-and-cudasw.md)
 > (the guest stack). The docs tree wins on disagreement.
 
-Status: 2026-11-09, tree `master @ df6e71bb`. Tags: `[live]` observed with the
+Status: 2026-11-11, tree `master @ 4acac093`. Tags: `[live]` observed with the
 stock guest driver; `[wip]` partial; `[wall]` current blocker; `[target]`
 defined success state.
 
@@ -82,15 +82,16 @@ Rated honestly, against the milestone ladder in the plan:
 | GR backend timeouts fixed (`backend_timeout=0`; draws retire in 3-2400 ms) | `[live]` |
 | DDX 3D replay executes (`section captured` + `GR LAUNCH` on `0x1000014`, 12 launches/cycle) | `[live]` |
 | First real GPU readback: pbuffer `glClear(red)+glReadPixels` -> `pixel=ff0000ff` | `[live]` |
+| First non-black GPU-rendered frames: 500/500 off-screen 640x480 frames, 45.4 s video captured (`r1769`) | `[live]` |
+| Direct-GL GR ring `0xbeef0100` resolves; releases advance frame by frame (`4acac093`) | `[live]` |
+| GZDoom passes `V_Init: allocate screen` with GL 4.6.0 when shared nvClip `modeNum` is even | `[live]` |
 | RM write-lock holder identified (Xorg in the DDX vidheap scrub wait) and fixed (`df6e71bb`) | `[live]` |
 | Engine executes a launch built from the captured section (real `sm_75` SASS retired) | `[live]` |
 | Verbatim 3D method-stream replay retired by the engine, no MMU fault | `[live]` |
 | X server survives the run on a 12 GB guest (the DDX's 4 GB sysmem allocation forces the size) | `[live]` |
-| Direct-GL channel `0xbfef0002` submits a captured draw (`ops_runs>0`) | `[wall]` |
-| Window/screen present completes without wedging X (ivshmem frame path) | `[wall]` |
-| X startup/RM stability (`0x51`, vmalloc 96 GB) | `[wall]` |
-| NVIDIA Vulkan ICD creates a device | `[wall]` |
-| Non-black screen rendered frames through the emulated vGPU | `[wall]` |
+| Direct-GL CE ring `0xbeef0101` resolves (GZDoom CE work executes) | `[wall]` |
+| Window/screen present produces non-black screen pixels | `[wall]` |
+| X startup/stability (`_nv052600rm` soft-lock, `0x51`, vmalloc) | `[wall]` |
 | 60 fps sustained, no forcing (M-GL4) | `[target]` |
 
 ## 4. How OpenGL runs are verified
@@ -110,20 +111,25 @@ The graphics plan defines M-GL1 (client context-init decodes and executes; the
 client leaves its retry loop), M-GL2 (`glxgears` non-black), M-GL3 (GZDoom GL
 non-black through the mdev), M-GL4 (60 fps, no forcing), M-GL5 (two VMs, two
 mdevs), M-GL6 (split-screen video). The project sits **between M-GL1 and
-M-GL2**: the interface and execution work is done — the display/KMS stack
-registers, X settles, the client submits and retires its GR/CE channels, and
-the first real GPU readback is proven (pbuffer `pixel=ff0000ff`). The
-remaining gates are the direct-GL client's draw submission/capture on
-`0xbfef0002` and the window/screen present path (a window draw currently
-wedges X) before the first rendered screen frame.
+M-GL2, with M-GL2's off-screen half proven**: the display/KMS stack registers,
+X settles, the client submits and retires its GR/CE channels, the direct-GL GR
+ring resolves and its releases advance, and the GPU-rendered pbuffer path
+produced non-black animated frames and a captured 45.4 s video. The remaining
+gates are the direct-GL CE ring `0xbeef0101`, the window/screen present path
+(a window draw currently wedges X and glxgears' window is black), and X
+stability across boots — then the first rendered screen frame.
 
 ## 6. What is not claimed
 
-* No OpenGL frame from the emulated vGPU has produced real rendered pixels
-  yet; every screen capture so far is black. The pbuffer probe renders and
-  reads back a red pixel, but the direct-GL client still emits only
-  setup/notify kicks, and a synchronous window draw wedges X. Those are the
-  current walls.
+* No **window/screen** frame has rendered real pixels through the emulated
+  vGPU yet; every screen capture so far is black. The non-black frames and the
+  video come from the off-screen pbuffer path (pbuffer -> sysmem -> kvmfr
+  ivshmem -> host reader), not from a windowed X screen capture. The direct-GL
+  CE ring `0xbeef0101` does not resolve, a synchronous window draw wedges X,
+  and X window creation wedges on some boots. Those are the current walls.
+* GZDoom reaching `V_Init: allocate screen` is not a rendered-frame claim; it
+  proves the client's GL init and the direct-GL GR lane, not the game loop or
+  a presented frame.
 * No frame-rate or latency numbers.
 * The published two-VM GZDoom demo videos used the labelled `virtio-gpu`/
   `virgl` path, not the emulated vGPU.
diff --git a/wiki/Physical-GPU-Backend.md b/wiki/Physical-GPU-Backend.md
index 181afa2..ee014ad 100644
--- a/wiki/Physical-GPU-Backend.md
+++ b/wiki/Physical-GPU-Backend.md
@@ -5,7 +5,7 @@
 > guest-facing emulation. Canonical sources: [`../docs/03-architecture/08-physical-gpu-integration.md`](../docs/03-architecture/08-physical-gpu-integration.md)
 > and [`../docs/03-architecture/11-physical-backend-guest-wiring.md`](../docs/03-architecture/11-physical-backend-guest-wiring.md); the docs tree wins on disagreement.
 
-Status: 2026-11-09, tree `master @ df6e71bb`. Tags: `[live]` proven with the
+Status: 2026-11-11, tree `master @ 4acac093`. Tags: `[live]` proven with the
 stock guest driver; `[gated]` implemented default-off; `[wip]` partially
 built; `[wall]` current blocker; `[target]` planned end state.
 
@@ -123,12 +123,13 @@ same machinery in three shapes (a verbatim 3D method-stream replay,
 synthesized launches, and the direct GL client's own GR/CE channels); the
 captured and synthesized streams execute on the engine, and the direct GL
 client's channels submit. The display/KMS stack registers, the X DDX waits are
-fixed, X is reliable, the DDX 3D replay executes and the first real GPU
-readback is proven (pbuffer red pixel), so the remaining graphics gates are
-the direct-GL draw submission/capture and the window/screen present before
-non-black screen pixels. The remaining compute work is the staged-transfer
-class (under repair), the every-boot acceptance campaign, and per-guest
-execution isolation — see
+fixed, X is reliable on good boots, the DDX 3D replay executes, and the first
+non-black GPU-rendered frames are proven (500/500 off-screen frames plus a
+45.4 s video); the direct-GL GR ring resolves with advancing releases, so the
+remaining graphics gates are the direct-GL CE ring `0xbeef0101`, the window/
+screen present, and X stability before non-black window pixels. The remaining
+compute work is the staged-transfer class (under repair), the every-boot
+acceptance campaign, and per-guest execution isolation — see
 [`Execution-Frontier.md`](Execution-Frontier.md) and
 [`Graphics-Execution.md`](Graphics-Execution.md).
 A failed mutating operation on the backend parks the device in a locked
diff --git a/wiki/Project-Goals.md b/wiki/Project-Goals.md
index 812ef3a..d1cef59 100644
--- a/wiki/Project-Goals.md
+++ b/wiki/Project-Goals.md
@@ -10,7 +10,7 @@
 > [`Execution-Frontier.md`](Execution-Frontier.md) and
 > [`Graphics-Execution.md`](Graphics-Execution.md).
 
-Status: 2026-11-09, tree `master @ df6e71bb`. Tags: `[live]` working with the
+Status: 2026-11-11, tree `master @ 4acac093`. Tags: `[live]` working with the
 stock guest driver; `[wip]` in progress; `[planned]` designed, not built;
 `[target]` bring-up ahead; `[non-goal]` explicitly out of scope.
 
@@ -46,12 +46,12 @@ drivers, no license.**
 
 ## 3. Goals and their status
 
-| Goal | What success looks like | Status (2026-10-30) |
+| Goal | What success looks like | Status (2026-11-11) |
 |---|---|---|
 | Stock guest driver initialisation | The unmodified driver probes, initialises and enumerates as on bare metal (`nvidia-smi`) | `[live]` — TU104 reference platform |
 | Full CUDA driver-API surface | Context creation, allocation, copies, free, destroy complete with correct results | `[live]` — the driver-API smoke prints `ALL OK`; the 64-byte payload round-trips |
 | CUDA kernel execution on real hardware | Verified guest kernels execute on the physical GPU, with engine-authored completions waking the guest | `[live]` — vector-add, matrix-multiply and transformer clients green on fresh boots; the staged-transfer class, the every-boot acceptance campaign and per-guest isolation are in progress ([`Execution-Frontier.md`](Execution-Frontier.md)) |
-| OpenGL (3D graphics) | Stock guest GL applications render real pixels through the emulated vGPU | `[wip]` — the display/KMS stack and X run (NvKms registers, `glxinfo` OpenGL 4.6.0 direct), the 2D path is green, the DDX 3D replay executes and the first real GPU readback is proven (pbuffer red pixel). Screen pixels remain the frontier: the direct-GL client channel `0xbfef0002` emits only setup/notify kicks, a window draw wedges X, and X startup/RM stability is not deterministic ([`OpenGL.md`](OpenGL.md)) |
+| OpenGL (3D graphics) | Stock guest GL applications render real pixels through the emulated vGPU | `[wip]` — the display/KMS stack and X run (NvKms registers, `glxinfo` OpenGL 4.6.0 direct), the 2D path is green, the DDX 3D replay executes, and the first non-black GPU-rendered frames plus a 45.4 s video are captured off-screen; the direct-GL GR ring resolves and GZDoom reaches `V_Init`. Window/screen pixels remain the frontier: the direct-GL CE ring `0xbeef0101` does not resolve, glxgears' window is black, and X window creation wedges on some boots ([`OpenGL.md`](OpenGL.md)) |
 | Vulkan | Stock guest Vulkan applications render real pixels | `[wip]` — the pipeline runs end to end (device → command buffer → fence → readback); frames are black — program delivery and program-VA mapping are the frontier ([`Vulkan.md`](Vulkan.md)) |
 | Windows guests (DirectX, CUDA) | A stock WDDM driver and stock D3D/CUDA applications run in Windows guests | `[target]` — not started; same emulation target ([`DirectX.md`](DirectX.md)) |
 | Video (NVENC/NVDEC) | Encode/decode through the emulated device | `[planned]` |
diff --git a/wiki/Project-Plan.md b/wiki/Project-Plan.md
index 5694a77..dd8de18 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 @ df6e71bb`. Tags: `[done]`, `[active]`,
+Status: 2026-11-11, tree `master @ 4acac093`. Tags: `[done]`, `[active]`,
 `[ahead]` — the plan's own state vocabulary, distinct from the goal tags.
 
 ## 1. How the plan works
@@ -40,11 +40,11 @@ itself:
 
 ## 2. The phases
 
-| Phase | What it delivers | Exit gate | State (2026-10-30) |
+| Phase | What it delivers | Exit gate | State (2026-11-11) |
 |---|---|---|---|
 | **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 DDX replay machinery work and the first real GPU readback is proven (pbuffer red pixel); the direct-GL draw capture, the window/screen present and X stability 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 with M-GL2's off-screen half proven: the display/KMS and DDX replay machinery work, the first non-black GPU-rendered frames and a 45.4 s video are captured, and the direct-GL GR ring resolves; the direct-GL CE ring, the window/screen present and X stability 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]` |
@@ -58,12 +58,14 @@ available (P5 runs across the whole plan).
 Ranked, in dependency order:
 
 1. **Graphics pixels (P2).** The client and display stacks execute, the
-   DDX 3D replay runs, and the first real GPU readback is proven (pbuffer
-   red pixel); the named walls are the direct-GL client's draw
-   submission/capture on `0xbfef0002` (setup/notify only, `ops_runs=0`), the
-   window/screen present path (a window draw wedges X), X startup/RM
-   stability (`0x51`), and the DDX's 4 GB sysmem allocation (12 GB guest
-   workaround), then non-black screen frames. Full detail:
+   DDX 3D replay runs, the first non-black GPU-rendered frames and a 45.4 s
+   video are captured off-screen, and the direct-GL GR ring `0xbeef0100`
+   resolves with advancing releases. The named walls are the direct-GL CE
+   ring `0xbeef0101` (it never resolves, so GZDoom wedges ~90 s after
+   `V_Init`), the window/screen present path (glxgears' window is black and a
+   window draw wedges X), X startup/stability (`_nv052600rm` soft-lock,
+   `0x51`, vmalloc), and the DDX's 4 GB sysmem allocation (12 GB guest
+   workaround), then non-black window 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
@@ -83,8 +85,10 @@ and its three wait fixes (class-aware display arm, `0x8000 -> 0` notification
 completion, decoded GL release applied); the GSP event-IRQ fix that completes
 swaps; the X DMA-init fix (`ebf3130f`); the GR backend timeout fix
 (`backend_timeout=0`); the 2D path end-to-end; the DDX 3D replay and the
-first real GPU readback (pbuffer `pixel=ff0000ff`); the RM write-lock holder
-fix (`df6e71bb`); and the guest Vulkan pipeline running end to end.
+first non-black GPU-rendered frames with a captured video (the ring-ledger
+scrub release, `f6184ac3`); the direct-GL GR ring resolution (`4acac093`);
+the RM write-lock holder fix (`df6e71bb`); and the guest Vulkan pipeline
+running end to end.
 
 ## 4. The gates
 
diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md
index f153bb9..137b7d9 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 @ df6e71bb`. Tags: `[live]` proven with the
+Status: 2026-11-11, tree `master @ 4acac093`. 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, X settles and `glxinfo` reports OpenGL 4.6.0 with direct rendering; the 2D path is green, the DDX 3D replay executes on `0x1000014`, and the **first real GPU readback** landed: a guest `glClear(red)+glFinish+glReadPixels` pbuffer probe returned `pixel=ff0000ff`. The RM write-lock holder (Xorg in the DDX vidheap scrub wait) was identified and fixed (`df6e71bb`). **No non-black screen pixels yet:** the direct-GL client channel `0xbfef0002` still emits only 32/64-byte setup/notify kicks (`ops_runs=0`, no captured draw), a synchronous window draw wedges X, and X startup/RM degradation (`0x51`) plus the DDX's 4 GB sysmem allocation (12 GB guest) remain ([`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 2D path is green, the DDX 3D replay executes on `0x1000014`, and the **first non-black GPU-rendered output** is proven: a pbuffer probe returns `pixel=ff0000ff`, the off-screen frame path produced 500/500 non-black animated frames, and a 45.4 s video was captured. The direct-GL **GR ring `0xbeef0100` now resolves** (its releases advance frame by frame), so GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context whenever the shared nvClip `modeNum` is even. **Window/screen pixels remain the wall:** glxgears' window is still black, the direct-GL **CE ring `0xbeef0101` never resolves** and the guest wedges ~90 s after `V_Init`, X window creation wedges on some boots (`_nv052600rm+0x7b`), and the DDX's 4 GB sysmem allocation forces a 12 GB guest ([`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]` |
@@ -76,10 +76,12 @@ 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); the first GPU readback is proven (a pbuffer probe
-returns a red pixel) and the DDX 3D replay executes, but the direct-GL client
-still emits only setup/notify kicks and a window draw wedges X, so screen
-capture is the frontier ([`OpenGL.md`](OpenGL.md)). The
+with direct rendering); the first non-black GPU-rendered frames are proven
+off-screen (the pbuffer path produced a 500-frame, 45.4 s video on the
+emulated vGPU) and the direct-GL GR channel now submits with advancing
+releases, but windowed/screen pixels remain the frontier (the direct-GL CE
+channel does not yet resolve and X window creation can wedge) — see
+[`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.
diff --git a/wiki/System-Overview.md b/wiki/System-Overview.md
index 9ad17e0..6ad4d3e 100644
--- a/wiki/System-Overview.md
+++ b/wiki/System-Overview.md
@@ -7,7 +7,7 @@
 > and [`../docs/03-architecture/10-interaction-and-scheduling.md`](../docs/03-architecture/10-interaction-and-scheduling.md)
 > for the full picture); the docs tree wins on disagreement.
 
-Status: 2026-11-09, tree `master @ df6e71bb`. Tags: `[live]` proven with the
+Status: 2026-11-11, tree `master @ 4acac093`. Tags: `[live]` proven with the
 stock guest driver; `[gated]` implemented default-off; `[wip]` partial;
 `[wall]` current blocker; `[target]` designed end state.
 
@@ -143,11 +143,13 @@ RPC from the guest to "firmware":
    nvidia-modeset/NvKms registers (`/dev/dri`), X settles and `glxinfo`
    reports OpenGL 4.6.0 with direct rendering; the direct GL client's
    channels submit, the X DDX waits are fixed, the DDX 3D replay executes,
-   the 2D path is green, the first real GPU readback is proven (pbuffer red
-   pixel), and the guest Vulkan pipeline runs end to end. The direct-GL client
-   still emits only setup/notify kicks and a window draw wedges X, so the
-   remaining gate is the direct-GL draw capture and the window/screen present
-   before the first non-black screen frame ([`OpenGL.md`](OpenGL.md),
+   the 2D path is green, the first non-black GPU-rendered frames and a
+   45.4 s video are captured off-screen, the direct-GL GR ring resolves with
+   advancing releases, and the guest Vulkan pipeline runs end to end. The
+   direct-GL CE ring `0xbeef0101` still does not resolve, a window draw
+   wedges X (glxgears' window is black), and X window creation wedges on some
+   boots, so the remaining gate is the window/screen present before the
+   first non-black window frame ([`OpenGL.md`](OpenGL.md),
    [`Vulkan.md`](Vulkan.md)).
 
 ## 6. Where the detail lives