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)

1 files changed, 53 insertions, 33 deletions

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.