diff options
Diffstat (limited to 'wiki/Project-Status.md')
| -rw-r--r-- | wiki/Project-Status.md | 17 |
1 files changed, 10 insertions, 7 deletions
diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md index 944e525..96e55db 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-10-30, tree `master @ b4930168`. Tags: `[live]` proven with the +Status: 2026-11-09, tree `master @ 4acc81e8`. 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. @@ -25,9 +25,10 @@ named success state; `[planned]` designed, not built. | Stock guest driver probe and `nvidia-smi` (TU104) | `[live]` working | | 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 in two lanes ([`Graphics-Execution.md`](Graphics-Execution.md)) | +| 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 X server and GLX run on the emulated vGPU with the stock driver, the engine executes real GL method streams (verbatim 3D replay plus synthesized launches), and a direct GL client creates its channels and readback path; rendered (non-black) frames are the frontier ([`OpenGL.md`](OpenGL.md)) | +| OpenGL (3D graphics) | `[wip]` — the display/KMS stack registers and X settles; `glxinfo` reports OpenGL 4.6.0 with direct rendering; GZDoom obtains a real GL context; the direct GL client's GR and CE channels submit and their releases land. **No rendered pixels yet:** the remaining gate is the X GLX context-creation completion (the X server spins in its RM ioctl path) plus the client kick-slot word; fullscreen GZDoom's mode set still wedges X, so the campaign uses a settled X + windowed GZDoom ([`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]` | @@ -64,8 +65,8 @@ The project's definition of done for CUDA requires all of the following Until every gate holds, the honest formulation is: **initialization, the driver-API path and kernel execution on the physical GPU work and verify; -the staged-transfer class, per-guest isolation and the graphics pixel -frontier remain.** +the staged-transfer class, per-guest isolation and the graphics +GLX-completion/first-frame frontier remain.** ## 3. How to see it yourself @@ -73,8 +74,10 @@ The reference setup takes about half an hour from a fresh host ([`Install-and-First-Run.md`](Install-and-First-Run.md)); the current expected 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 X server and -GLX on the emulated vGPU ([`OpenGL.md`](OpenGL.md)). 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); rendered pixels remain the frontier +([`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. |