diff options
Diffstat (limited to 'wiki/Project-Status.md')
| -rw-r--r-- | wiki/Project-Status.md | 17 |
1 files changed, 9 insertions, 8 deletions
diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md index 3e7c54f..d556f4f 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-13, tree `master @ 436cbf9d`. Tags: `[live]` proven with the +Status: 2026-11-14, tree `master @ 339da842`. 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. @@ -26,9 +26,9 @@ named success state; `[planned]` designed, not built. | CUDA userspace init and the driver-API smoke (`cuInit`, device enumeration, `cuCtxCreate`, allocation, copies, free, destroy) | `[live]` working — the smoke prints `ALL OK` and the 64-byte payload round-trips exactly | | Guest CUDA kernel execution on real hardware | `[live]` working — verified green on fresh boots: the vector-add (`VADD n=32768 bad=0`), matrix-multiply (`MATMUL n=256 bad=0`) and transformer (`dh=256 seq=64 bad=0`, `FFN4 layers=4 bad=0`) clients print `STATUS OK`, engine-authored completions relay to the guest and its synchronisation waits resolve. A ring-block ownership defect that could stall the first client after a reboot was root-caused and fixed. Remaining: the staged-transfer class (some large multi-chunk clients still mis-verify; the failure modes are proven and under repair) and per-guest execution isolation for simultaneous CUDA guests | | 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 X DDX idle-DMA/ScreenInit, USERD-latch lifetime, re-probe-thrash, Xorg kernel-mode-spin and flip-event walls were closed in the 11-12/11-13 wave (X green for >10 minutes in a validated window), leaving a per-boot first-generation X lottery (an X started immediately after boot passes DDX DMA init; 3/7 windows); the display-capability seam is parameterised ([`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 X DDX idle-DMA/ScreenInit, USERD-latch lifetime, re-probe-thrash, Xorg kernel-mode-spin and flip-event walls were closed (X green for >10 minutes in a validated window); what remains is the per-boot **first-generation X start lottery**, which by 11-13/11-14 was the dominant throughput limiter for the graphics A/B runs (only an X started immediately after boot passes DDX DMA init; long stretches of dead starts, one green first-start boot). 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 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:** the lookalike gate and the live-PA-bound fix (10 GiB raised to the registered guest-RAM top, 14 GiB) now let the client's 13+ GiB page directories walk and decode real GR method streams, and its GR ring resolves through its own VAS; but the GL setup push (59,556 bytes at VA `0x4001004`) and the draw pushes (`0x4250000`/`0x4250110`) still resolve to zero/implausible PAs because their user/UVM VAS is never registered, so no draw section opens for `0xbeef0100` and the window stays black. The engine-zero-write campaign showed the store wall is upstream of the draw (the replayed 221-word window is draw-free); the window/screen present path is unproven, and the X screen-init first-generation lottery remains ([`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 direct-GL submission is now fully decoded:** no client push carries a method-grammar draw header — the channel's 9 NV906F entries tile one contiguous buffer and its per-frame work is carried as rewritten data-block blobs plus small state pushes (324/476/728 B) that invoke MME macros (the QMD-carrier hypothesis was tested and refuted). A content-gated FB-shadow rescue and a LOW-band rescue recover the recycled pushes: the client's draw-state push now opens a C597 section, is captured and marked for the verbatim 3D lane (the first direct-GL stream3d marks), and reaches the engine (`GR LAUNCH submitted`/`OK`, golden MME overlay accepted). **The current wall is MME macro completion:** the beef lane's 2799-word packed program cannot complete inside its <=2048-word block together with the 156-400-word draw window, so the load-only carrier gate drops each beef window and `live_gen` never promotes (a multi-part keep-window mechanism is committed default-off and enabled in the campaign params; A/B pending). RT routing was tested and refuted as the store cause (RT0 bind verified 16x but still `wrote=0`), and the earlier `CODESRC` fault-park class is prevented (zero `FAULT_PDE`/`WEDGE-REARM` on the validated boot). The window stays black (`px0=0`, `wrote=0`); the window/screen present path is unproven, and the X start lottery is the throughput limiter ([`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]` | @@ -79,11 +79,12 @@ stack and the X server on the emulated vGPU (`glxinfo` reports OpenGL 4.6.0 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 payload VAs -still resolve to zero/implausible PAs because their user/UVM VAS is never -registered, and X screen-init keeps a first-generation lottery) — see -[`OpenGL.md`](OpenGL.md). The +GZDoom reaches its screen-allocation stage with GL 4.6.0 on an even modeNum. +The direct-GL submission is fully decoded (no classic draw header; the work is +macro-driven and the client's state push now reaches the engine), but +windowed/screen pixels remain the frontier (the MME multi-part program cannot +yet complete, the store still misses, and X start keeps a first-generation +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 tooling used to study the firmware side of that frontier. |