From 25e3e800df8e5caf18d7e846a0cd36df4f5834f9 Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Tue, 10 Nov 2026 16:42:39 -0500 Subject: wiki: 2026-11-10 afternoon refresh - first real GPU readback; direct-GL/window walls Refresh STATE-CURRENT, the Main Page and the status/frontier pages: the DDX 3D replay executes and a guest pbuffer glClear+glReadPixels returns a red pixel (ff0000ff); the RM write-lock holder (Xorg in the DDX scrub wait) is fixed in df6e71bb. The direct-GL client channel still emits only setup/notify kicks (ops_runs=0), a window draw wedges X, and X startup/RM stability plus the DDX 4 GB sysmem allocation remain. Published to open-iov.org. --- STATE-CURRENT.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) (limited to 'STATE-CURRENT.md') diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 79154d3..7c43dea 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,5 +1,45 @@ # Open-IOV Current State +> **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).** -- cgit v1.2.3