diff options
Diffstat (limited to 'STATE-CURRENT.md')
| -rw-r--r-- | STATE-CURRENT.md | 714 |
1 files changed, 699 insertions, 15 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 27295df..5762b4f 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,12 +1,667 @@ # Open-IOV Current State -> **Snapshot: 2026-10-20 ~20:00 (two more fixes landed: the SWAP_RX cursor -> and the pin-wins ledger divergence that cured a guest-kernel-corruption -> panic; guest CUDA kernels green on fresh boots - `victory_mail`, -> `victory_matmul` (first-run flake), transformer, `vector_add` (1M, -> `bad=0`), `vecadd_loop` (100 launches); two guests with two emulated VRAM -> sizes (512M + 1GiB) coexist live; frontier = the multi-pass content class -> and the streams2 launch-order wait).** +> **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 +> `glClear(red)+glFinish+glReadPixels` pbuffer probe returned +> `rc=0 err=0x0 pixel=ff0000ff` (r1734), with the host logging +> `section captured` plus `GR LAUNCH submitted` on the DDX channel +> `0x1000014`. That proves the emulated path can render and read back through +> the unmodified guest driver. The RM write-lock holder was identified as +> Xorg in the DDX vidheap scrub wait (NVOS32 `ALLOC_SIZE` 0xa0000, spinning +> on `vmap+0x6c004`); `df6e71bb` authors the all-ones release pair for a +> scanner-registered scrub buffer with no USERD GP_PUT, which released the +> lock and made the readback work. +> +> Still open: the direct-GL client channel `0xbfef0002` opens a C597 section +> but emits only 32/64-byte setup/notify kicks (`ops_runs=0`, `section +> captured`/`GR LAUNCH` 0) - the GL draws never reach the host. A synchronous +> window draw wedges X (`xwd -root` writes 0 bytes) while the pbuffer probe +> works, so screen capture must use the ivshmem frame path. X startup remains +> a lottery (`Failed to initialize DMA` / push-buffer `0x51` / occasional +> vmalloc 96 GB) and X can die after forward activity. No non-black screen +> pixels yet. Milestone position: between M-GL1 and M-GL2; the readback pixel +> is execution proof, not a screen frame. +> +> Walls ranked: (1) direct-GL draw submission/capture on `0xbfef0002`; +> (2) window/screen present and X stability; (3) X startup/RM degradation +> (`0x51`); (4) the DDX 4 GB sysmem allocation/OOM (12 GB guest); (5) +> non-black screen frames and sustained rate. +> +> 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): host up ~42 h (fresh boot 2026-11-08 22:29); +> `vgsp` loaded + live cycle (QEMU 128357, mdev +> `c949938a-0391-4aa0-8d49-1679878fe5cd`); `tree` has the campaign's in-flight +> kernel/tool work (HEAD `df6e71bb`); pstore empty; no reboot during the +> check. +> +> **Snapshot: 2026-11-10 ~06:10 (SESSION 156 continued; HEAD `bb802909`, +> tree has in-flight kernel work from the campaign; supersedes the 05:30 +> entry below).** +> The X and GR reliability work landed. `ebf3130f` fixes the X DMA-init path +> (the pristine-FB USERD scan now runs when the ring is present but unusable, +> the foreign-FB claim is offset-correct, the parked VAS candidate is +> content-validated at the pump turn, and the owner-VAS fallback covers +> `hVASpace==0`) and flips the GR pair-close/pair-safe replay fixes to default +> ON. Result: **X direct rendering green on attempt 1 in three consecutive +> cycles (r1687/1688/1689)**, `backend_timeout=0` (was 6), `backend_ok=5-7`, +> and draws retire in 3-2400 ms. `bb802909` (WIP beef-ring promote + +> draw-channel CB scan) is committed; the campaign has uncommitted kernel work +> in flight. +> +> The remaining wall is still the **replayed draw writes 0 pages** (render +> target unchanged; `bounce copy-out` reports 0 changed). It is now precise: +> (1) the beef GR ring resolution race - `0xbeef0100` registers with `vas=0` +> before its CE siblings publish `0xbeef0300`; the VAS is then registered +> UNVERIFIED by the 1 ms age-out, so the ring at `0x4020000` stays +> `ring_pa=0` and the fixed-CB scan (gated to the `0xbeef0000` family) never +> runs. The fix is to gate the candidate promote on *verified* rather than +> *known* and retry every pump turn. (2) Even when the scan runs (`r1687`), it +> decodes 1492 `0x3800` offsets plus 1497 `0x39c8` data runs (1092 words) but +> the image's `0x80` MVP block is zero; identified parser bugs (subchannel +> bits 15:13, `0x238c` ONE_INC inline data, selector B/C swap) are not yet +> applied, and the MVP may live at an offset >= `0x1000` or a selector B/C +> binding. (3) The render-target bind (`svc_surf_prelude_capture`, +> last-trusted-bind-wins) must be confirmed to match the page the copy-out +> compares. +> +> The 2D path is green end-to-end, the guest's real GL draws forward and +> execute on the physical GPU, and X is reliable; no rendered pixel through +> the emulated vGPU yet. Milestone position: between M-GL1 and M-GL2. +> Estimate (subjective): first non-black frame hours-to-days if the beef-ring +> and CB decode behave like their predecessors; the two-VM GPU-accelerated +> video after that. +> +> 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): r1691 VM up (QEMU 80456, mdev +> `eba5a4f0-ef85-4ea5-9fb4-4ef1a6b04a3b`), X green on attempt 1, glxgears +> 300x300 black, `work_gr backend_ok=5 timeout=0`, `bounce copy-out 0 +> changed`, beef ring unresolved; `vgsp` loaded (HEAD `bb802909` plus the +> campaign's in-flight kernel work), `guest_ram active=1`; pstore empty; no +> reboot during the check. +> +> **Snapshot: 2026-11-10 ~05:30 (SESSION 156 continued; HEAD `cb8e822b`, +> tree clean, `vgpu/master` in sync; supersedes the 19:15 entry below).** +> The execution chain came alive overnight. The guest's **real GL draws now +> forward and execute on the physical GPU** (`work_gr backend_ok=9` on r1683, +> `backend_ok=5` on r1685), the 2D path is green end-to-end (accelerated X +> fills read back correctly via `xwd`), and the earlier glxgears poll hang is +> gone: the GSP event-IRQ fix (`a478f0b4`) now sets the RISC-V SWGEN0 +> IRQSTAT/IRQMASK/IRQDEST and latches the CPU-tree leaf so the guest services +> the event. The working recipe is a 12 GB file-backed guest +> (`-object memory-backend-file ... /dev/shm/vgpu-guest-ram`), the +> `gsp-phys-guest-ram` debugfs translation, the RM-call ladder stages 5/3/4, +> the full r1624 module-argument set, and `sema_vas_cand_ms=1` (which made X +> green on attempt 1 in r1685). The beef GR channel `0xbeef0100` now captures +> real GL draw sections (`len=4808`, `win=1201 words`, `prog=0x4390900`). +> +> The new frontier is the **constant buffer**: the draw executes but the +> engine writes 0 pages, and `bounce copy-out` reports 0 changed. The GL +> draw's constant-buffer source is forced to the seed page because +> `sema-gl: cb-copy src=0x0cd70000 ... first8=00000000 ... src=synthetic-id` +> reads all zeros; a guest-RAM scan found no MVP matrix, and the +> `0x3f800000` hits in vidmem are shader microcode immediates, not matrices. +> With a zero MVP every vertex collapses to the origin, so there are no +> fragments regardless of viewport/render-target. The next step is to decode +> the CB-bind method on the beef channel, resolve that VA through the channel +> VAS, and copy the real page into the seed page. Secondary walls: the MME +> front-end busy/deferred class, the GR stale-wedge recovery, the X DDX +> push-buffer get-word/notifier recycle (X can still die after a few forward +> frames into the RM-degraded state), and the DDX's 4 GB sysmem allocation +> that forces the 12 GB guest. +> +> Honest state: still no rendered pixel through the emulated vGPU and no +> video. The execution chain (submit -> forward -> physical GR -> stores) is +> now live for the guest's own GL work; the first pixel is gated on the MVP +> constant-buffer content and the present/copy-out. Milestone position: +> between M-GL1 and M-GL2. Estimate (subjective): a first non-black frame +> hours-to-days if the constant-buffer decode behaves like its predecessors; +> the two-VM GPU-accelerated video after that. +> +> 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): r1685 VM up (QEMU 72960, mdev +> `0dcda61f-a8ef-4111-8993-35942d2d5392`), X green, glxgears 300x300 +> rendering black, `work_gr backend_ok=5`; `vgsp` loaded (HEAD `cb8e822b` +> plus the runtime parameters above), `guest_ram active=1`, ladder stage 4; +> pstore empty; no reboot during the check. +> +> **Snapshot: 2026-11-09 ~19:15 (SESSION 156 continued; HEAD `21e0d611`, +> tree clean; supersedes the 19:05 entry below).** +> The forced-GLX path moved the renderer wall: with +> `SDL_VIDEO_X11_FORCE_EGL=0` + OpenGL, GZDoom and glxgears now use +> `libnvidia-glcore` (the EGL/Mesa fallback is gone). The minimal windowed +> reproducer (`glxgears`) then hangs in the glcore kick wait: the client polls +> the per-slot `/dev/nvidia-modeset` fd (`poll(POLLIN, 1 s)`); the host's +> sweep completes the beef notifier memory (`kick-slot completed +> h=0xbeef0101 ...`, `client-slot cleared h=0xbeef0100`), but the guest kernel +> never signals the event the poll waits on. The remaining edge is +> kernel-visible completion: complete the exact notifier page the guest +> kernel watches and signal the guest event (the kick-notify executor), not +> just write the memory. GZDoom's window creation fails/hangs at the same step +> and can still allocate the DDX's 4 GB sysmem block, which occasionally OOMs +> the 12 GB guest. +> +> Current walls, ranked: (1) the kernel-visible GL present/kick completion +> above; (2) the X DDX push-buffer get-word/notifier recycle (a diagnostic +> get-word write released the DDX and let GZDoom reach `MAP01` on llvmpipe +> earlier, but the kernel lever is not implemented); (3) the DDX's 4 GB +> sysmem allocation (12 GB guest workaround; suspected emulation gap); (4) +> the direct-GL draws still report `forwarded=0` - decoded and host-completed, +> not dispatched to the physical GR engine. No rendered frame through the +> emulated vGPU yet; the earlier `MAP01` was a llvmpipe datapoint, not the +> target. Milestone position: between M-GL1 and M-GL2. +> +> 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): host up 20 h (fresh boot 2026-11-08 22:29); +> `vgsp` loaded (refcount 0) + mdev +> `d22c826b-871d-4540-9fc6-63cf3e87f823` + QEMU r1679 live (12 GB guest, +> glxgears spinning); `nvidia-smi` reports no supported GPU (the vgsp claim +> is held); pstore empty; no reboot during the check. +> +> **Snapshot: 2026-11-09 ~19:05 (SESSION 156 continued; HEAD `e342bd0f`, +> tree clean, `vgpu/master` in sync; supersedes the 12:45 entry below).** +> Since the 12:45 entry the campaign closed the X-side execution machinery +> and moved the pixel gate to concrete blockers. The X server's deaths were +> separated from driver bugs: the DDX waits are fixed by `408d67d3` +> (class-aware display arm - the 0xc57e window class has no NOTIFY bit, so a +> bound notifier is the arm; bfef `0x8000 -> 0` NvNotification completion; +> the decoded GL release is applied via `sema_gl_hold_apply`, default off; +> the 0x8000 sweep is extended to the X DDX's own RM channels), on top of the +> PMA-scrub deadlock fixes (`3701f985`, `ad93b227`) and the channel-VAS push +> read (`c3887218`). The residual death is an OOM: the X DDX allocates 4 GB +> of system pages at startup (kprobe and gdbstub: `nv_alloc_pages` count +> 1048576 from Xorg), which an 8 GB guest cannot absorb once GZDoom adds its +> own footprint; the current run uses a 12 GB guest. +> +> With the DDX unblocked, GZDoom reached `MAP01` for the first time, but on +> **Mesa llvmpipe**: the NVIDIA Vulkan ICD fails `vkCreateDevice` and the +> default OpenGL/EGL path falls back to Mesa (`libEGL ... failed to create +> dri2 screen`). The emulated-vGPU render path is therefore not the one that +> rendered; the campaign is forcing GLX (`SDL_VIDEO_X11_FORCE_EGL=0`) on the +> 12 GB run and has fully decoded the DDX push-buffer wait: the 2D reserve +> exits only when the GPU-written engine get word advances (`get <= put`) and +> the kick requires the notifier to be recycled to `0xffff` after completion. +> A diagnostic host write of the get word released the loop and let GZDoom +> reach `MAP01`; the kernel levers (publish/advance the get word; recycle the +> notifier) are the next implementation. +> +> Honest state: still no rendered frame through the emulated vGPU and no +> video; GZDoom's `MAP01` is a llvmpipe datapoint, not the target. Milestone +> position: between M-GL1 and M-GL2. Current walls, ranked: (1) renderer +> selection - the NVIDIA Vulkan ICD must create a device or the forced-GLX +> path must reach glcore; (2) the DDX push-buffer get-word/notifier +> completion; (3) the 4 GB X DDX sysmem allocation (suspected emulation gap) +> that forces the 12 GB guest; (4) the direct-GL draws still report +> `forwarded=0` - decoded and host-completed, not dispatched to the physical +> GR engine. Estimate (subjective): a first NVIDIA-path frame hours-to-days +> if these behave like their predecessors; the two-VM GPU-accelerated video +> after that. +> +> 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): host up 20 h (fresh boot 2026-11-08 22:29); +> `vgsp` loaded (refcount 0) + mdev +> `d3a9e554-f948-45df-b81b-b5e987b0bee8` + QEMU r1678 live (12 GB guest); +> `nvidia-smi` reports no supported GPU (the vgsp claim is held); pstore +> empty; no reboot during the check. +> +> **Snapshot: 2026-11-09 ~12:45 (SESSION 156; HEAD `4acc81e8`, tree clean, +> `vgpu/master` in sync; supersedes the 2026-11-06 ~19:00 entry below).** +> The graphics front moved from the DS SPH validation gate to a working +> display/GL stack with one named X-side completion wall. Since 11-06 the +> 38-commit arc ending at `4acc81e8` landed: the host-side EVO display engine +> (`035d033c`: core/window/imm channels 0xc57d/0xc57e/0xc57b, NV-DMA push +> parser, SET_NOTIFIER/UPDATE-FINISHED, raster line) makes the guest display +> chain real only with `disp_caps_seed=1` (the caps window reads all-zero +> otherwise -> "Unsupported base display class"); the display instance table +> is resolved in the guest BAR2 aperture as Linux enumerates it (BAR3) and +> notifier writes are routed by target (FB shadow vs guest PA); +> `SET_NOTIFIER_DMA` is `valid=1` and `UPDATE -> FINISHED` is 12/12; lost +> completion events are force-retried. With that, nvidia-modeset/NvKms +> register (`/dev/dri/card0` + `renderD128` + `fb0`, `nvidia-smi -L` green), +> X settles, `glxinfo` reports OpenGL 4.6.0 NVIDIA 570.144 with direct +> rendering, and GZDoom obtains a real GL context. The approved reboot +> (2026-11-08 22:29) cleared the stale host GSP-RM state that had wedged +> every boot in `NV_ESC_RM_VID_HEAP_CONTROL`; post-reboot runs reproduce +> none of it. +> +> The windowed path then exposed and closed three completion walls: +> (a) the UVM channel-pool tracker - a channel rank N owns pool slot N (the +> earlier rank+1 model pre-satisfied the next rank and lost the write), the +> release is fanned through every published VAS translation (the pool page +> moves between RM-memdesc and VAS-walk pages; `80cbbd04`, `a3060a54`) and +> the init slot escalates 1..4 (`f10714c9`), so six UVM channels now pass +> their init waits; (b) the direct-GL GR release - the deferral is scoped to +> the push's own candidate (a global cross-pass arm let stale candidates +> defer every later release; `1ad9216a`) and `sema-sw` writes now land for +> `beef0100`; (c) the direct-GL CE channels `beef0101/0102` - a VRAM-shape +> USERD scan for the beef CE family (`f2476897`) finds their rings and their +> submissions retire; the X DDX kick channel `bfef0002` decodes its ring head +> without a USERD and authors the class-2d notification (`4acc81e8`). +> Fullscreen GZDoom's mode set still wedges X; the campaign path is a +> settled X + windowed GZDoom. +> +> Honest state: GATE1 still not met - no rendered GZDoom frame and no +> emulated-vGPU video. Current wall (r1664): Xorg spins ~30-41% CPU in +> `_nv018351rm` while GZDoom blocks on the X GLX reply +> (`_xcb_wait_for_reply`) then returns to its glcore spin. The remaining +> objects are the X RM ioctl behind `_nv018351rm`, the X GLX +> context-creation completion (direct-GL channel completion vs a display +> flip notifier), and the GZDoom kick-slot word (not the RM notifier page). +> Milestone position: between M-GL1 and M-GL2 (the client and display stacks +> execute; pixels are the gate). Estimate (subjective): a first windowed +> GZDoom frame hours-to-days if the wall behaves like its predecessors; the +> two-VM GPU-accelerated video follows after a real frame, with 60 fps/no +> forcing weeks after that. +> +> 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. Watch next: the +> `_nv018351rm` ioctl identification, the X GLX completion object, and the +> client kick-slot word - then a rendered windowed GZDoom before any +> capture. +> +> Live at check (read-only): host up 14 h (fresh boot 2026-11-08 22:29); +> `vgsp` loaded (refcount 0) + mdev +> `dc0cfb79-fd4e-490a-8f08-e5228caeaed0` + QEMU r1664 live; `nvidia-smi` +> reports no supported GPU (the vgsp claim is held); pstore empty; no +> reboot during the check. +> +> **Snapshot: 2026-11-06 ~19:00 (SESSION 155 continued; r1562 committed +> post-reboot; HEAD `2f5b838c`, 1 unpushed; supersedes the ~12:55 entry +> below).** The DS SPH validation wall narrowed to a single bit this +> afternoon: r1562 (per-stage synth SPH disable mask, `2f5b838c`) reached +> `ds 80000000->81040000` = **SPH18 only** (GS check2, the geometry-stage +> attribute map) with the client's own stage VAs +> (0x01990900/0x01990300/0x01990200/0x01990000 across j0/j1/j2/j5). Two +> fixes got there: the pair-safe synth bind (`fe03bfe8`) emits the class's +> own END ahead of a carried-open BEGIN/END pair and orders TYPE/ +> REGISTER_COUNT before the SPH address pair - the r1558 EC 0x0d +> ILLEGAL_METHOD_IN_BEGIN_END class is gone (r1560: 13 beef launches, +> 3 DS-FAST, 0 Class Error); and the client's own stage-disable records +> (`0x2000<-0`, `0x2080<-0x20`, `0x20c0<-0x30`, `0x2100<-0x40`) cleared +> the VSB 5/7 tess-mode pair (r1561), proving the DS validates every +> stage - even a disabled one. The DS bitmap is decoded: `SPH<n>`, +> n = stage*4 + check over VSA/VSB/TCS/TES/GS/PS, with four checks +> (type/version, mpipe/stage binding, attribute map, stream-out). +> +> The r1562 run then poisoned (`badf1201` priv-error, TSG preempt + +> resched) and entered the known GR timeout/wedge cascade (MME-REGS / +> FETCH-WIT / MME-FAST spin, 18:47:21); the VM was closed and the host was +> rebooted cleanly (logind `systemd-reboot` 18:47:20-24; pstore empty, no +> crash). The reboot is not recorded in the acting handoff (last write +> 17:59) - reason inferable from dmesg; no post-reboot plan written +> there. Post-reboot: fresh boot 18:47:56; apt nvidia 570.211.01 green +> (RTX 2080 Super Max-Q); `vgsp` was down at the check moment; the acting +> session resumed the stack at 18:56 (vfio prereqs) and r1563 is in +> preparation (18:57). +> +> Afternoon wave since the 12:55 entry: `5fad0adb` (slot-selective +> `sema_sph_bind_mask`), `c822fa34` (engine-visible MME selector + RT0 +> third-dimension seeds), `3bb62602` (bounded setup-push hold; hold>0 +> stalls the ring behind the unreadable 60216 B setup entry - 0 is the +> reproducible base), `fe03bfe8` (pair-safe + per-stage bind disable), +> `91a4b48e` (docs: real render walls), `2f5b838c` (r1562). Earlier in +> the wave (r1541-r1558): the PS-stage-only bind, the `0x2390` +> CB-selector poison fix, the EC 0xd2 colour-target third-dimension +> decode and the completed RT0 bind - the draw validates and stage5 +> populates. +> +> Honest state: GATE1 still not met - r1561's two captures 60 s apart are +> identical and nonblack=0 (black 800x600 window and black root); the +> best copy-out is 1-2 engine-changed pages that do not land on the +> visible surface. Milestone position: between M-GL1 and M-GL2. Estimate +> (subjective): GS 18 is a single named wall (GS-specific attribute/ +> stream state - glxgears emits no GEOMETRY SPH), first non-black frames +> hours-to-days if it behaves like its predecessors; 60 fps/no-forcing +> and a video on the emulated vGPU weeks after that; full CUDA breadth, +> multi-VM and Windows months. +> +> 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. Watch next: +> r1563's DS bitmap (does GS 18 clear?), then a non-poison DS transition +> with >2 changed pages before any pixel capture. +> +> **Snapshot: 2026-11-06 ~12:55 (SESSION 155 continued; r1538 live; +> HEAD `81bde9b7`; supersedes the ~01:00 entry below).** The graphics +> campaign moved from "the DRAW macro executes" to "**the first calls-kept +> draw windows execute with engine-authored stores, and the DS SPH +> validation is the last gate before pixels**". The fixed-CB upload is +> decoded end-to-end (MME-wrapper form, the assembler image delivered to +> the engine-visible seed page, real-CB receipts gating it). The +> class-error wall that had kept the first calls-kept window from +> executing was a BEGIN/END pair carried across the window boundary; +> `81bde9b7` (`sema_gl_pair_close_entry`) emits the driver's own END form +> (`0x1614` + event word) before the first window run when the tracker +> carries an open pair. r1529 (P0 config + close): 44 beef launches, +> **0 Class Error**, `mac=0x22` x16, and 1-2 engine-changed copy-out +> pages per launch - the slot-34 DRAW_IAB macro (IRAM entry 0x265, 75 +> words) executes (r1526, before the fix: 11 launches, first calls-kept +> window poisoned at SET_FRONT_FACE `0x191c`, error 0x0d +> ILLEGAL_METHOD_IN_BEGIN_END). +> +> The close is not default yet: r1532 (close + SPH window 0x10004) +> misfired after 14 failed launches - the injected END itself faulted +> (`0x1614`, error 0x0d) because the tracker believed a pair was open +> that the front end had already lost - so it stays default-off until the +> pair model is committed only on retire. The SPH version window is not +> the DS gate: r1535 (P0 + close + `sema_sph_version_val=0x10004`) ran 49 +> launches with 0 Class Error and `mac=0x22` x18, but the DS still +> escalated `80000000->84000420->86040624->86040666` and only 1-2 pages +> changed (seed bi=768, clear bi=772/773). The DS signature +> (`stage=00000000,01990900,01990200,00000000,00000000,01990000`, +> `region=0/0`) is SPH2|SPH5|SPH9|SPH10|SPH18 with M_PIPE_STAGE=VSB|TI; +> the three stage VAs are legal V4 headers, so the failing entries are +> channel-level (cache/other binds), not those headers. Ranked next: +> (1) skip binds whose page does not start with SPH version 4 +> (`sema_sph_bind_filter`, receipt `SPH-BIND-FILTER`); (2) emit the +> program region as one 2-word INC run and fix the MME shadow read index +> to `(mthd >> 2) & 0xfff` before trusting the `scratch[0x78]` evidence; +> (3) make the pair model transactional (commit pair state only on +> retire, then re-enable pair-close by default); (4) sweep every bound +> SPH VA's first word and the per-stage bind list. +> +> Live at check (read-only): host up 5 h 13 m (fresh boot this morning); +> `vgsp` loaded (refcount 0) + mdev +> `c71c1617-b502-4ff0-9659-64df695aaa27` + QEMU 484365; r1538 (SPH +> bind/region experiment) is live and left running; its early receipts +> show `SPH-BIND emitted` and `SPH-REGION emitted` (bases +> 0x1500000/0x15c0000/0x1990000/0x1ab0000), mixed 1-2/0 changed-page +> copy-outs, and a 0-byte screen-capture fetch (no non-black frame yet); +> `pstore` empty; no reboot during the check (in-session cycles only); +> HEAD `81bde9b7` == `vgpu/master`, tree clean; `nvidia-smi` reports no +> GPU (the vgsp claim is held). +> +> CUDA front (backgrounded while the graphics campaign holds the device; +> its 10-30 status stands): the physical-engine path is green +> (`41343c63`; `victory_mail` `VADD bad=0` + `STATUS OK`; `vecadd_loop` +> 100 launches PASS); the fresh-boot battery's red class is D2H-stage +> (release-before-work, ledger-vs-writer divergence, memset +> readback/writeback race - all proven; release-discipline fixes staged, +> not yet validated); the SESSION 143 Vulkan fence/completion regression +> is still not re-measured, and the guest Vulkan pipeline renders +> end-to-end but black (the inline-to-memory upload arm is its named +> gap). Two guests with two mdevs coexist at boot level (guest-B CUDA +> awaits per-guest ownership). The Vulkan black-frame path and the GL +> pixel gate are separate; the GL draw is the one currently executing. +> +> Honest state: GATE1 is not met - the X screen is black/static and the +> best capture remains the earlier 2.08% non-black static twin frames +> (not pixels); the app's ~450 FPS is fence-level completion. The +> milestone position is between M-GL1 and M-GL2 (the gate = a swap-hook +> capture with real motion). Estimate (subjective): first non-black +> frames hours-to-days if the DS gate behaves like its predecessors; +> 60 fps / no-forcing and a video on the emulated vGPU weeks after that; +> full CUDA breadth, multi-VM and Windows months. Watch next: r1538's DS +> result, the SPH bind-filter / region-form fixes, and a first non-black +> xwd on a fresh cycle. +> +> **Snapshot: 2026-11-04 ~12:45 (graphics-execution campaign, SESSION +> 153/154 continued, r1442-r1451; HEAD `bbda751e`, tree clean, +> `vgpu/master` in sync).** Since the 10-30 snapshot the active front is +> **graphics execution**: the emulated vGPU went from "the method stream +> retires but writes nothing" to "the direct GL client's DRAW macro +> executes to completion and the engine writes pages - rasterised pixels +> are the remaining wall". Engine-verified milestones since 10-30: the +> first beef launches retiring (`fdfb4673`) and the byte-exact +> present-blit proof (`eef52abe`); the first full window retire +> (`e3ecd6a3`) and the DRAW-class window retire with stubbed macros +> (`8528df77`); full MME macro-program capture with the offline proof that +> the packed image equals the live program (`66d95894`, `ffaa39f3`); the +> first engine store retirements (`output retirement 2/901 pages changed`, +> CONT-104) with `0x2390` root-caused to LOAD_CONSTANT_BUFFER and the +> constant-buffer-selector slot fix; the MME IRAM readback gate whose live +> debug-port reads match the packed image at macro entry, and slot-57 +> macro execution to its last instruction with stores growing 9 -> 238 -> +> 305 of ~903 (CONT-107/CONT-109, `8df33f1f`, `0eb64118`); the first +> engine-changed render-target pages in the completion copy-out (r1385, +> CONT-111); SESSION 154's client-formation protocol (one X-client +> teardown + re-create makes formation reliable), the golden macro overlay +> (`94c432d9`) and the first slot-34 (DRAW_IAB) execution via the +> pipeline-stage bind lever (`b0171765`); and the 11-03/11-04 +> release-sequencing wave (settle hold, strict release, front-end-busy +> deferral, window hold) plus the pipeline-binding emission fix +> (`79545530`) together with carrying the program-address pair - the two +> walls that blocked the called-macro path (`0x2090` binding rejection, +> the VA-0 constant fetch) are down: on the best boot both called macros +> reach their ends (slot 57 `mpc=930`, slot 2 `mpc=22`), 9 launches clean +> (7 consecutive), store retirements and engine-changed copy-out pages +> observed. Current graphics walls (ranked): (a) residual per-launch +> poison classes under the call/window-content lottery (`0x2390` LCB, +> `0x1614`, the `0x100 deaddead` cascade), with levers built or in flight - +> the latest (`bbda751e`) drops the attr-prelude SET_PIPELINE run the front +> end refuses cold; (b) the newly named **raster blocker** - draws retire +> without storing to the X framebuffer, so render-target/surface binding +> is the next gate; (c) the present/capture path once (b) lands. Honest +> state: GATE1 is not met - the X screen is static/black and the guest +> glxgears window reads 2.08% non-black static twin frames (not pixels); +> the app loop's ~450 FPS is fence-level completion, not rendering; the +> milestone position is between M-GL1 and M-GL2 (the gate = a swap-hook +> capture with real motion). **CUDA front (backgrounded while the +> graphics campaign holds the device; its 10-30 status stands):** the +> physical-engine path is green (`41343c63` cross-class ring-claim fix; +> `victory_mail` `VADD bad=0` + `STATUS OK`; `vecadd_loop` 100 launches +> PASS); the fresh-boot battery's red class is D2H-stage +> (release-before-work, a ledger-vs-writer divergence, a memset +> readback/writeback race - all proven; release-discipline/opdef-deadline +> fixes staged, not yet validated); the SESSION 143 Vulkan fence/ +> completion regression is still not re-measured, and the guest Vulkan +> pipeline renders end-to-end but black (the inline-to-memory upload arm +> is its named gap). Two guests with two mdevs coexist at boot level +> (guest-B CUDA awaits per-guest ownership). Live at check (read-only): +> host up 1 d 20 h; `vgsp` loaded (refcount 0) + mdev +> `6daed337-d05d-4185-a6fa-5a978d7d1cc7` + QEMU `e726ba0b`; campaign r1451 +> in flight (the run at the check instant showed the known +> WEDGE-REARM/`-110` failure class); pstore empty; `nvidia-smi` reports no +> GPU (the claim is held). Commits this arc (about 90, +> `fdfb4673`..`bbda751e`): the retire ladder, `2bc41213`..`ffaa39f3` +> (first stores), `8df33f1f`/`0eb64118`/`e2560a54` (macro completion, +> engine-changed pages), `94c432d9`, `b0171765`, and the SESSION 154 +> ladder `63541b75`..`bbda751e`. +> +> **Snapshot: 2026-10-30 ~12:20 (SESSION 153, r1013 live; HEAD `a64169db`).** +> The arc since the SESSION 143 snapshot split in two. Guest CUDA on the +> physical engine: the post-reboot stall is root-caused and fixed - the GR +> ring-autopin fallback and the CE first-submission capture each guarded +> block ownership only within their own engine class, so a channel could +> latch a live foreign FB block (`41343c63`: cross-class block claims, +> pre-latch CE reservations, own-block latch semantics) - and the fixed +> build is green repeatedly (`victory_mail` `VADD bad=0` + `STATUS OK`; +> `vecadd_loop` 100 launches PASS). The fresh-boot battery's remaining red +> class is D2H-stage (release-before-work, a ledger-vs-writer page +> divergence and a memset readback/writeback race are all proven; +> release-discipline fixes are staged but uncommitted; the opdef-deadline +> slot-complete path is the next fix). X/GL on the emulated vGPU: the wall +> that stood since the early sessions is closed - `fffae7b1` gets Xorg `:0` +> through the nvidia-push DMA sanity push and ScreenInit (`glxinfo` = +> OpenGL 4.6.0 NVIDIA 570.144, direct rendering, GZDoom launches), with the +> RC watchdog channel registered/serviced (`8898bd00`+`42c9626b`) and +> per-client VAS resolution (`38ba1e2d`: a channel's VAs resolve through +> its own VAS first). The app-side 10 s/frame waits are the client's own +> give-up manager; the `sema_xw_mirror` pair completes presents (glxgears +> latches 128-146 FPS, 200+ in the later shim runs) but produces no +> rendered output - the GL draw stream is marshalled, not executed. The +> engine now executes the real GL method stream in two forms: the C597 +> section capture + synthesized compute launch retires its QMD on real +> sm_75 SASS (`0ee574a3`..`595e023a`), and the verbatim 3D method-stream +> replay lane retires real 3D methods with no QMD (r932); the hard limit +> is that rasterised GL pixels still need the real 3D pipeline. SESSION +> 153's headline: the direct GL client's device-init gate is root-caused to +> the driver-shared memfd slot word (bit 0 set = glcore skips its +> class-0xc46f channel creation); cleared, the client allocates its +> channels (0xbeef0100/0101/0102 plus 0x902d/0xc5b5/0xc597/0x9072/0xa140/ +> 0x90f1) and `glReadPixels` returns with GL error 0 - fixed field-side by +> the kernel keeper `sema_shared_hold_pa` (`a64169db`, holds bit0 clear +> deterministically) plus host hold/toggle automation (the MakeCurrent +> handshake needs the 2<->3 transition). Current walls (ranked): (a) the +> fresh-boot Xorg DMA-init failure in r1013 (a 10 s `Failed to initialize +> DMA` -> no X server, so no client; a different wait from the member-spin +> class); (b) the client PUT-visibility wall - the direct client's channels +> never submit (its process writes no GP_PUT anywhere, the BAR0/BAR1-shadow +> premise was falsified by direct measurement, and the submitting DDX-side +> channel's USERD is guest RAM already tracked by the RAM scan); (c) the +> pixel wall - no render content reaches any ring (X-side pushes are 32-64 +> B housekeeping BEGINs; every capture/readback is black). Landmine: +> killing/exiting a direct client can trip a 4 GB `nv_alloc_system_pages` +> guest-kernel oops - never kill clients; re-cycle instead. Delivered on +> the emulated vGPU: the R18 CUDA-animation video (`70134652`; 60/60 +> frames zero faults, frames exact vs CPU math, single-page kernels only - +> the window-0 code shadow carries one 4 KB page, so kernels >4 KB stay +> hostile until it grows) and two two-VM GZDoom videos (`375d627a` tools; +> the GPU-accelerated one runs on virtio-gpu/virgl on the host iGPU, not +> the emulated vGPU, which remains the core frontier). Host clean, pstore +> empty; live: r1013 mdev `95446a6c-d5da-4e74-920b-5ac0d7ccc303`, QEMU +> 2335256, guest no Xorg/no GL client, pin/sem helpers up. Also open: the +> SESSION 143 Vulkan-client completion regression (fence timeout with the +> push re-completed) - not re-measured since r816, priority moved to the +> GL path. Commits this arc: `41343c63`, `fffae7b1`, `8898bd00`, +> `42c9626b`, `38ba1e2d`, `6f2e6193`, `0ee574a3`..`595e023a`, `70134652`, +> `375d627a`, `1fd8d50a`, `f500779b`..`a64169db` (SESSION 153 ladder). +> +> **Snapshot: 2026-10-26 (SESSION 143, post-reboot).** The r800 walk guard +> holds and the `gsp_phys_gr_min_data=0` bypass reaches the real engine: the +> guest Vulkan compute launch is now *submitted* (no oops, no degenerate-set +> refusal), the engine fetches the host-deposited QMD and the firmware reports +> a real `MMU Fault ... @ 0xdf_d8feb000, FAULT_PDE` at the guest program VA - +> the channel/context are alive, the program page is empty and unmapped. The +> util-sweep channel-visibility work (per-channel begin/skip/read=none lines) +> proves the Vulkan copy-class channels (0xbeef0101/0xbeef0102, engines 11/12) +> are registered and swept but never pushed, and that no channel carries +> program bytes or a `LAUNCH_DMA`: the code page (0x62b000 / rotating 0xc8b000) +> never fills. The frontier is therefore (1) the driver's staging-ring -> +> code-heap upload copy, which is not among the decoded pushes, and (2) the +> engine page-table mapping for the program VA. Separately, the refusal path no +> longer reaches the earlier three-black-frame baseline (`SYNTH-FAULT` vs the +> software completion/fence ordering), which must be restored before further +> observation. Docs: `docs/04-implementation/04-real-render-walls.md` sections +> 20-21. Commits: `34e611f4`, `c5510744`, `28def33e`, `0ca8ff9f`. +> +> **Snapshot: 2026-11-06 ~01:00 (the guest's REAL Vulkan pipeline now +> renders on the emulated vGPU: the first `VKFRAME seq=1..3` / +> `VKFRAME_DONE frames=3 640x480 saved=3` / `VKFRAME_IDLE ok` runs +> end-to-end — instance, device, allocation, image/view/buffer/shader/ +> descriptor/pipeline/command-buffer/fence, queue submit, fence release +> and frame readback all complete with a zero-touch service pipeline. +> The chain of fixes behind it: the push-stream parser now accepts the +> driver's real shapes (the `0x0001fff0` SET_SUBDEVICE_MASK bracket and +> zero NOP gaps — the class that silently skipped every large push), the +> fence fold (`sema_gr_ahead`) sweeps the pre-built GPFIFO continuation +> beyond GP_PUT and applies the submit's INC-5 RELEASE groups +> forward-only, the host-triggered VAS page-directory anchoring verifies +> the parked `COPY_SERVER_PDES` candidate against a content-located ring +> pair so the walk resolves every push VA before its first read, the +> COMPR+2MB VidHeap class is downgraded at the ioctl so +> `vkAllocateMemory` succeeds, the SEC2 scrubber's finish payload is +> authored by the service, the `0x9096` VidHeap enumeration and the +> `FIFO_GET_ENGINE_CONTEXT_PROPERTIES` ZCULL geometry are answered, and +> the C5C0-section -> vendor-launch translator found the real dispatch +> (a `SET_INLINE_QMD_ADDRESS_B` + 64-word run building QMD `0x4b85f00`, +> grid 40x30, plus the C5B5 copy-out). The frames are still BLACK: the +> driver delivers SASS/descriptors through its MME program + inline-to- +> memory stream (decoded in full; the payload rides the next GPFIFO +> entry as a source-view call), and the utility/copy-channel +> `LOAD_INLINE_DATA` arm that must materialize those writes is the +> current frontier (arbitration + `sema-utildec` witness landed). CUDA +> meanwhile: the best fresh-boot battery is 8 pass / 3 fail / 1 hang +> (the Vulkan work does not regress CUDA; always battery-first on a +> fresh boot); GL runs on the guest GPU (next wall = the FBO class); the +> Looking Glass frame path is proven end-to-end (guest render -> KVMFR +> ivshmem -> host PNG frame); two guests with 512M + 1GiB emulated VRAM +> coexist at boot level; the 0.9.9 release-preview demo video v1 is +> synced to files.vgpu.io (the updated video with GZDOOM working is the +> next publish). Frontier = non-black frames, then Xorg -> GZDOOM +> (GL/Vulkan) -> KVMFR/LG frames -> CUDA 15/15 + soak -> the perfect +> 1.0.0 video -> Windows guests).** > This is a dated public > status page, not live state; it is refreshed on every progress check. Live > working notes are maintained outside this repository; the public @@ -23,6 +678,20 @@ program against the physical TU104 backend (a `vectorAdd`-class kernel whose results verify), then the remaining open gates (multi-VM, 3D, Windows, isolation, performance, portability). +**Graphics objective (companion).** Land the first rasterised frame from an +unmodified guest graphics client on the emulated vGPU - the graphics ladder +**M-GL1** (client context-init executes) -> **M-GL2** (`glxgears` non-black +with motion) -> **M-GL3** (GZDoom GL through the mdev) -> **M-GL4** (60 fps, +no forcing) -> **M-GL5/M-GL6** (two VMs; video) - with gate definitions in +[`docs/04-implementation/05-graphics-execution-plan.md`](docs/04-implementation/05-graphics-execution-plan.md). +The current position is between M-GL1 and M-GL2: the display and GL stacks +now execute in the guest (NvKms registers, `/dev/dri`, X settles, `glxinfo` +4.6.0 direct, GZDoom obtains a real GL context) and windowed GZDoom reaches +renderer startup; the remaining gate is the X RM ioctl / GLX completion path +before a rendered frame (see the snapshot above). Both objectives are needed +for the 1.0 mission; the CUDA front is backgrounded while the graphics +campaign holds the device. + **Status.** - **Emulation front: GREEN.** The driver-API smoke completes end-to-end @@ -515,11 +1184,24 @@ isolation, performance, portability). can drive the host-owned device to an ECC Xid; shadowed BAR2 prevents it - committed and holding, no Xid since). Recurring and separate: guest-kernel boot panics (a NULL-in-interrupt/swap class) can kill a no-claim run at startup - - guest-side only, host stays healthy. A new host panic class was logged - 2026-10-05 11:18 with the (saved, reverted) pool-write-refusal experiment: a - sleeping VFIO mutex taken in atomic context in the sema GMMU walk plus a - vmalloc fatal exception in the bridge marshal path; reboot recovered the - host, no Xid. + guest-side only, host stays healthy. A new host panic class was logged + 2026-10-05 11:18 with the (saved, reverted) pool-write-refusal experiment: a + sleeping VFIO mutex taken in atomic context in the sema GMMU walk plus a + vmalloc fatal exception in the bridge marshal path; reboot recovered the + host, no Xid. +5. **Graphics execution (the display/GL campaign; current top front).** The + production display and GL stacks now run end-to-end in the guest - the host + EVO display engine serves the push-buffer channels, NvKms registers, X + settles, `glxinfo` is green and GZDoom obtains a real GL context - and the + direct-GL GR/CE channels submit. The remaining gates are: (a) the X RM + ioctl behind `_nv018351rm` and the GLX context-creation completion + (direct-GL channel completion vs a display flip notifier); (b) the GZDoom + kick-slot word (the client polls a kick-slot GPU VA, not the RM notifier + page); (c) the raster/present path once (a)-(b) complete. Fullscreen + GZDoom's mode set still wedges X; the campaign path is a settled X + + windowed GZDoom. GATE1 (a non-black frame with motion) is unmet. Full + context: the 2026-11-09 and 2026-11-06 snapshots above and + [`docs/04-implementation/05-graphics-execution-plan.md`](docs/04-implementation/05-graphics-execution-plan.md). ## Options to accelerate debugging toward end-to-end CUDA (candidate techniques; not directives) @@ -671,9 +1353,11 @@ meant to execute on the physical GPU. | CUDA userspace: `cuInit`, `cuDeviceGetCount`, `cuDeviceGet` | ✅ | | `cuCtxCreate` returns | ✅ (the whole smoke test now completes) | | `cuMemAlloc` + `cuMemcpy` roundtrip (`ALL OK` in the smoke test) | ✅ payload roundtrip verified 64/64 in the guest | -| Full `nvidia-smi` output / kernel launch | 🟡 the static runtime initializes end-to-end with **real releases** and the launch now executes through the host bridge (see next row); a full `nvidia-smi` (per-process/utilization) remains unverified | -| CUDA kernel execution (`vectorAdd`) | ✅ **First green end-to-end guest CUDA (2026-10-04 ~16:20, no-claim host bridge):** `MAIL` + `VADD n=1048576 bad=0 checksum=392344090.500000` + `STATUS OK`, three consecutive deterministic supervised cycles, committed `cf6ff542`. The vadd runs through the host CUDA bridge daemon; forwarding guest engine work to the real GPU is the remaining backend path. | -| Graphics (3D), video | ❌ | +| Full `nvidia-smi` output / kernel launch | 🟡 the static runtime initializes end-to-end with **real releases**; a full `nvidia-smi` (per-process/utilization) remains unverified | +| CUDA kernel execution (`vectorAdd`) | ✅ **Guest CUDA executes on the physical GR engine (host bridge disabled, since 2026-10-14):** `victory_mail` `VADD bad=0` + `STATUS OK` and `vecadd_loop` 100 launches PASS; matmul/transformer green after the 2026-10-20 boot-lottery fix (`c72f8948`). Remaining red class: the D2H-stage data classes (release-discipline fixes staged); launch-latency robustness; then battery/soak/multi-tenant breadth. | +| Graphics execution - OpenGL/X on the emulated vGPU | 🟡 the production display/GL stack now runs: nvidia-modeset/NvKms register (`/dev/dri/card0`, `renderD128`, `fb0`; `nvidia-smi -L`), X settles, `glxinfo` reports 4.6.0 (NVIDIA, direct rendering), GZDoom obtains a real GL context, and the direct-GL GR/CE channels submit (`beef0100/0101/0102`); the UVM channel-pool, GR release-deferral and CE USERD walls are closed. **No rendered frame yet:** the remaining gate is the X RM ioctl/GLX completion (`_nv018351rm`) plus the client kick-slot word; fullscreen GZDoom's mode set still wedges X, so the campaign uses a settled X + windowed GZDoom. Ladder position: between M-GL1 and M-GL2. | +| Vulkan on the emulated vGPU | 🟡 the guest pipeline renders end-to-end but black; the inline-to-memory upload arm is the named gap; the SESSION 143 fence/completion regression is still open. | +| Video | 🟡 R18 CUDA-animation video on the emulated vGPU (60/60 frames, exact vs CPU math); two two-VM GZDoom videos (the GPU-accelerated one is the labelled virtio-gpu/virgl path, not the emulated vGPU); the two-VM GPU-accelerated GZDoom video on the emulated vGPU is not yet produced. | | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ | Test status is tracked with the CUDA driver-API smoke test |