From 76a2d3cb16ea5550fb2f11f39a78b9eaa2804314 Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Thu, 12 Nov 2026 20:01:07 -0500 Subject: docs: 2026-11-12 status refresh - green X/GLX, non-black GPU captures, direct-GL stream frontier Refresh STATE-CURRENT.md and the open-iov.org wiki pages with the 2026-11-12 state: stock-driver X + GLX green (glxinfo 4.6.0 direct rendering, glxgears ~520 FPS), the pbuffer frame path captured 500/500 non-black frames (50 s 640x480 h264) plus the earlier 45.4 s capture, and the named frontier (direct-GL client command-stream delivery: setup push unreadable, CE ring 0xbeef0101 intermittent) alongside the guest-init/sizing fixes (RMInstLoc modprobe single-source, FB info in KB, 256 MiB GART). --- wiki/Project-Status.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) (limited to 'wiki/Project-Status.md') diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md index 137b7d9..8d34d70 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-11, tree `master @ 4acac093`. Tags: `[live]` proven with the +Status: 2026-11-12, tree `master @ 800c108f`. 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 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)) | +| OpenGL (3D graphics) | `[wip]` — the display/KMS stack registers, X and the stock NVIDIA GLX path are fully green (`glxinfo -B` returns 0 with OpenGL 4.6.0 and direct rendering; `glxgears` renders ~520 FPS with the emulated GPU's NVIDIA renderer), and the **first non-black GPU-rendered output** is proven: the pbuffer frame path produced 500/500 non-black 640x480 frames per run and captured videos (45.4 s on 2026-11-11; a 50 s 640x480 h264 capture on 2026-11-12). GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context whenever the shared nvClip `modeNum` is even. **The frontier is delivery of the direct-GL client's own command stream:** its 59,556-byte setup push is not yet resolvable/readable host-side while the client's page-directory incarnation churns, so its draw sections never reach the engine and the window stays black; the window/screen present path and the X DDX screen-init idle-DMA lottery are the other named blockers ([`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,11 +76,13 @@ 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 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 +with direct rendering, `glxgears` renders ~520 FPS); the first non-black +GPU-rendered frames are proven off-screen (the pbuffer path produced a +500-frame 45.4 s video on 2026-11-11 and a 50 s capture on 2026-11-12), and +GZDoom reaches its screen-allocation stage with GL 4.6.0 on an even modeNum, +but windowed/screen pixels remain the frontier (the direct-GL client's +command stream does not yet reach the engine and X screen-init is a per-boot +lottery) — 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 -- cgit v1.2.3