From f89fcb14ccdf9e8faf07ac42970c98f3ba7959f2 Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Thu, 1 Oct 2026 00:06:19 -0400 Subject: docs: refresh status wording after the 64/64 baseline and the physical-backend lock --- docs/README.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) (limited to 'docs/README.md') diff --git a/docs/README.md b/docs/README.md index 284ca76..5f9a32f 100644 --- a/docs/README.md +++ b/docs/README.md @@ -98,7 +98,7 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai- ## 3. Where is the project today? -**Honest status (2026-09-29):** +**Honest status (2026-10-01):** | Area | State | |------|-------| @@ -107,8 +107,8 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai- | GSP-RM message queue + RPC transport | ✅ Working | | GSP-RM controls: device/fb/bus tables, CE caps, vaspace, GMMU static info | 🟡 Mostly — the engine inventory now includes the async copy engine and the CE capabilities match the device; reply fidelity for the remaining consumed fields is still being tightened | | Guest `nvidia.ko` probe, `nvidia-smi` | ✅ Working (TU104) | -| Guest CUDA driver (`libcuda`) startup | 🟡 Partially — `cuInit` and device enumeration work; the client reaches `cuCtxCreate` and currently ends in a forced `999` on a completion wait while the completion/translation plumbing is made reliable. See [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md) and [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) | -| CUDA kernel execution | 🔴 Not yet — context creation must complete first, then real work forwarding; the execution backend is chosen but not started ([`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md)); today only decoded memsets/copies/semaphore releases execute, in the host | +| Guest CUDA driver (`libcuda`) startup | ✅ Driver-API baseline — `cuInit`, device enumeration, `cuCtxCreate`, `cuMemAlloc`, copies, free and destroy complete end to end; the smoke test prints `ALL OK` and the 64-byte payload round-trips exactly (64/64, re-verified 2026-10-01 on the current build). See [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md) and [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) | +| CUDA kernel execution | 🔴 Not yet — the runtime client initializes and the kernel launch is queued, but execution awaits the backend; the mechanism is chosen (module-owned GPU + real GSP session) with ownership + firmware staging verified and the power-domain lock implemented pending supervised verification ([`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md)); the real GSP boot has not started, and today only decoded memsets/copies/semaphore releases execute, in the host | | OpenGL / Vulkan | 🔴 Not yet | | Windows guest | 🔴 Not yet | | Multi-tenant isolation (VFs, mdev-per-VM) | 🟡 Designed, partially implemented | @@ -116,14 +116,17 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai- We also know exactly where the CUDA bring-up stands and what the next step is: the userspace `libcuda` segfault was fixed (an RM allocation reply now echoes the request parameters instead of returning zeros), the engine inventory is -complete, and the client reaches context creation, which currently ends on a -completion wait while decoded work is made to execute reliably. The full +complete, and the driver-API smoke test now completes end to end — `cuCtxCreate` +returns and the 64-byte payload round-trips exactly (64/64, re-verified +2026-10-01 on the current build). The full mechanism, with offsets and the decompiled call path, is in [`../userspace/cuda/docs/05-570.144-decompilation.md`](../userspace/cuda/docs/05-570.144-decompilation.md). -Beyond that, the missing piece for kernel execution is forwarding the guest's -*work* (push buffers, page trees, execution) to the physical GPU under our -control; the chosen backend — a module-owned GPU running its real GSP firmware -as the resource-manager server — is specified in +The remaining frontier is real execution on the physical GPU: the runtime client +initializes and queues a kernel launch, but does not execute it. The chosen +backend — a module-owned GPU running its real GSP firmware as the +resource-manager server — has verified ownership + firmware staging and an +implemented (pending supervised verification) power-domain lock; the real GSP +boot has not started. It is specified in [`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md). For the visual end-state map and the cross-component call paths, see -- cgit v1.2.3