site: 2026-10-30 wiki refresh - new Project Goals, Performance and Interfaces and Stability pages; GSP explainer expanded (bare-metal behaviour + the two emulation modes); graphics pages (Graphics Execution, OpenGL, Vulkan, DirectX) with two new diagrams; status refresh across 15 pages; canonical docs updated (README status table, purpose-and-scope, performance contract); published to open-iov.org (67 pages, 0 problems)

1 files changed, 20 insertions, 14 deletions

diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md
index e63a198..944e525 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-20, tree `master @ 16291c72`. Tags: `[live]` proven with the
+Status: 2026-10-30, tree `master @ b4930168`. 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.
@@ -24,11 +24,13 @@ named success state; `[planned]` designed, not built.
 | GSP-RM message queues and RPC transport | `[live]` working |
 | 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. Remaining: the large-buffer staged-transfer class is under repair (some large multi-chunk clients still mis-verify); fresh-boot re-measurement is in progress after the boot-poisoning fix; per-guest execution isolation for simultaneous CUDA guests is in progress |
-| 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 |
-| 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; per-guest execution isolation for simultaneous CUDA guests is in progress |
-| OpenGL / Vulkan (3D), video | `[planned]` |
-| Windows guests | `[planned]` (target) |
+| 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)) |
+| 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)) |
+| 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]` |
 | Xen / Argo / OpenXT / Qubes Air transports | `[planned]` (the emulation core is hypervisor-independent by construction) |
 | Live migration | `[planned]` |
 | Performance numbers | `[planned]` — no published numbers yet; any claim will ship with its measurement methodology |
@@ -50,17 +52,20 @@ The project's definition of done for CUDA requires all of the following
 5. Correct completion, semaphore and fault semantics back to the guest — the
    GR completion path now relays (engine-authored releases wake the guest's
    synchronisation waits); fault semantics remain partial.
-6. Reproducibility: every boot, not a lucky one — root-caused and fixed (the
-   boot-poisoning defect: the wrong status-queue consumption cursor could
-   desynchronise the reply ring under load and poison the boot);
-   re-measurement across fresh boots is in progress.
+6. Reproducibility: every boot, not a lucky one — two root causes landed: the
+   boot-poisoning defect (the wrong status-queue consumption cursor could
+   desynchronise the reply ring under load) and the ring-block ownership
+   defect that could stall the first client after a reboot. Green clients are
+   reproduced across fresh boots; a formal every-boot acceptance campaign is
+   the remaining work.
 7. No ad-hoc default-off parameters required for the canonical path — still
-   open.
+   open (the forwarding and graphics seams remain parameterised while they
+   are validated).
 
 Until every gate holds, the honest formulation is: **initialization, the
 driver-API path and kernel execution on the physical GPU work and verify;
-hardening (large-buffer transfers, boot-to-boot reproducibility) and
-per-guest isolation remain.**
+the staged-transfer class, per-guest isolation and the graphics pixel
+frontier remain.**
 
 ## 3. How to see it yourself
 
@@ -68,7 +73,8 @@ 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. 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
 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.