diff options
Diffstat (limited to 'wiki/Project-Status.md')
| -rw-r--r-- | wiki/Project-Status.md | 11 |
1 files changed, 6 insertions, 5 deletions
diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md index 96e55db..4ee4b50 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-09, tree `master @ 4acc81e8`. Tags: `[live]` proven with the +Status: 2026-11-09, tree `master @ e342bd0f`. 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 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)) | +| OpenGL (3D graphics) | `[wip]` — the display/KMS stack registers and X settles; `glxinfo` reports OpenGL 4.6.0 with direct rendering; the direct GL client's GR and CE channels submit and their releases land; GZDoom reaches renderer startup and `MAP01`, currently on Mesa llvmpipe. **No rendered pixels through the emulated vGPU yet:** the walls are the NVIDIA Vulkan ICD/forced-GLX renderer path, the X DDX push-buffer get-word/notifier completion, the DDX's 4 GB sysmem allocation (12 GB guest workaround), and the direct-GL draws' physical dispatch (`forwarded=0`) ([`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]` | @@ -66,7 +66,7 @@ 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 -GLX-completion/first-frame frontier remain.** +renderer/DDX-completion/first-frame frontier remain.** ## 3. How to see it yourself @@ -76,8 +76,9 @@ 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); rendered pixels remain the frontier -([`OpenGL.md`](OpenGL.md)). The +with direct rendering); GZDoom reaches renderer startup but currently falls +back to Mesa llvmpipe, so the NVIDIA renderer path and the DDX completion are +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. |