diff options
Diffstat (limited to 'wiki/Project-Status.md')
| -rw-r--r-- | wiki/Project-Status.md | 13 |
1 files changed, 7 insertions, 6 deletions
diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md index 4ebf765..5115706 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 @ cb8e822b`. Tags: `[live]` proven with the +Status: 2026-11-09, tree `master @ bb802909`. 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 GSP event-IRQ fix completes swaps, the 2D path is green end-to-end, and the guest's **real GL draws now forward and execute on the physical GPU** (`work_gr backend_ok=9`; glxgears swaps, black). **No rendered pixels through the emulated vGPU yet:** the draw writes 0 pages because its constant-buffer (MVP) page is unresolved/zero and is forced to the seed page; the MME front-end defer, GR stale-wedge, X DDX get-word/notifier completion and the DDX's 4 GB sysmem allocation (12 GB guest) are the remaining walls ([`OpenGL.md`](OpenGL.md)) | +| OpenGL (3D graphics) | `[wip]` — the display/KMS stack registers, X settles and `glxinfo` reports OpenGL 4.6.0 with direct rendering; the GSP event-IRQ fix completes swaps, the 2D path is green end-to-end, and the guest's **real GL draws forward and execute on the physical GPU** (`work_gr backend_ok=5-7`, `backend_timeout=0`); the X DMA-init path is fixed (`ebf3130f`) so X is green on attempt 1 in three consecutive cycles. **No rendered pixels through the emulated vGPU yet:** the replayed draw writes 0 pages; the walls are the beef GR ring resolution race (the fixed-CB scan only runs on `0xbeef0100`, whose ring at `0x4020000` is unresolved), the fixed-CB image's `0x80` MVP block being zero (1092 words decoded; parser bugs identified), and the render-target bind matching the copy-out; the DDX's 4 GB sysmem allocation (12 GB guest) remains ([`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 -MVP-content/present/first-frame frontier remain.** +beef-ring/CB/first-frame frontier remain.** ## 3. How to see it yourself @@ -76,9 +76,10 @@ 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 guest's GL draws execute on the physical GPU and -glxgears completes swaps, but the constant-buffer (MVP) page does not resolve, -so the frames are black ([`OpenGL.md`](OpenGL.md)). The +with direct rendering); X is green on attempt 1, the guest's GL draws retire +and execute on the physical GPU, and the 2D path is green, but the draw still +writes 0 pages because the beef-ring/CB/render-target chain does not resolve +([`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. |