diff options
| -rw-r--r-- | STATE-CURRENT.md | 104 |
1 files changed, 96 insertions, 8 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 441ea85..17332ca 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,5 +1,68 @@ # Open-IOV Current State +> **Snapshot: 2026-11-04 ~12:45 (graphics-execution campaign, SESSION +> 153/154 continued, r1442-r1451; HEAD `bbda751e`, tree clean, +> `vgpu/master` in sync).** Since the 10-30 snapshot the active front is +> **graphics execution**: the emulated vGPU went from "the method stream +> retires but writes nothing" to "the direct GL client's DRAW macro +> executes to completion and the engine writes pages - rasterised pixels +> are the remaining wall". Engine-verified milestones since 10-30: the +> first beef launches retiring (`fdfb4673`) and the byte-exact +> present-blit proof (`eef52abe`); the first full window retire +> (`e3ecd6a3`) and the DRAW-class window retire with stubbed macros +> (`8528df77`); full MME macro-program capture with the offline proof that +> the packed image equals the live program (`66d95894`, `ffaa39f3`); the +> first engine store retirements (`output retirement 2/901 pages changed`, +> CONT-104) with `0x2390` root-caused to LOAD_CONSTANT_BUFFER and the +> constant-buffer-selector slot fix; the MME IRAM readback gate whose live +> debug-port reads match the packed image at macro entry, and slot-57 +> macro execution to its last instruction with stores growing 9 -> 238 -> +> 305 of ~903 (CONT-107/CONT-109, `8df33f1f`, `0eb64118`); the first +> engine-changed render-target pages in the completion copy-out (r1385, +> CONT-111); SESSION 154's client-formation protocol (one X-client +> teardown + re-create makes formation reliable), the golden macro overlay +> (`94c432d9`) and the first slot-34 (DRAW_IAB) execution via the +> pipeline-stage bind lever (`b0171765`); and the 11-03/11-04 +> release-sequencing wave (settle hold, strict release, front-end-busy +> deferral, window hold) plus the pipeline-binding emission fix +> (`79545530`) together with carrying the program-address pair - the two +> walls that blocked the called-macro path (`0x2090` binding rejection, +> the VA-0 constant fetch) are down: on the best boot both called macros +> reach their ends (slot 57 `mpc=930`, slot 2 `mpc=22`), 9 launches clean +> (7 consecutive), store retirements and engine-changed copy-out pages +> observed. Current graphics walls (ranked): (a) residual per-launch +> poison classes under the call/window-content lottery (`0x2390` LCB, +> `0x1614`, the `0x100 deaddead` cascade), with levers built or in flight - +> the latest (`bbda751e`) drops the attr-prelude SET_PIPELINE run the front +> end refuses cold; (b) the newly named **raster blocker** - draws retire +> without storing to the X framebuffer, so render-target/surface binding +> is the next gate; (c) the present/capture path once (b) lands. Honest +> state: GATE1 is not met - the X screen is static/black and the guest +> glxgears window reads 2.08% non-black static twin frames (not pixels); +> the app loop's ~450 FPS is fence-level completion, not rendering; the +> milestone position is between M-GL1 and M-GL2 (the gate = a swap-hook +> capture with real motion). **CUDA front (backgrounded while the +> graphics campaign holds the device; its 10-30 status stands):** the +> physical-engine path is green (`41343c63` cross-class ring-claim fix; +> `victory_mail` `VADD bad=0` + `STATUS OK`; `vecadd_loop` 100 launches +> PASS); the fresh-boot battery's red class is D2H-stage +> (release-before-work, a ledger-vs-writer divergence, a memset +> readback/writeback race - all proven; release-discipline/opdef-deadline +> fixes staged, not yet validated); the SESSION 143 Vulkan fence/ +> completion regression is still not re-measured, and the guest Vulkan +> pipeline renders end-to-end but black (the inline-to-memory upload arm +> is its named gap). Two guests with two mdevs coexist at boot level +> (guest-B CUDA awaits per-guest ownership). Live at check (read-only): +> host up 1 d 20 h; `vgsp` loaded (refcount 0) + mdev +> `6daed337-d05d-4185-a6fa-5a978d7d1cc7` + QEMU `e726ba0b`; campaign r1451 +> in flight (the run at the check instant showed the known +> WEDGE-REARM/`-110` failure class); pstore empty; `nvidia-smi` reports no +> GPU (the claim is held). Commits this arc (about 90, +> `fdfb4673`..`bbda751e`): the retire ladder, `2bc41213`..`ffaa39f3` +> (first stores), `8df33f1f`/`0eb64118`/`e2560a54` (macro completion, +> engine-changed pages), `94c432d9`, `b0171765`, and the SESSION 154 +> ladder `63541b75`..`bbda751e`. +> > **Snapshot: 2026-10-30 ~12:20 (SESSION 153, r1013 live; HEAD `a64169db`).** > The arc since the SESSION 143 snapshot split in two. Guest CUDA on the > physical engine: the post-reboot stall is root-caused and fixed - the GR @@ -129,6 +192,17 @@ program against the physical TU104 backend (a `vectorAdd`-class kernel whose results verify), then the remaining open gates (multi-VM, 3D, Windows, isolation, performance, portability). +**Graphics objective (companion).** Land the first rasterised frame from an +unmodified guest graphics client on the emulated vGPU - the graphics ladder +**M-GL1** (client context-init executes) -> **M-GL2** (`glxgears` non-black +with motion) -> **M-GL3** (GZDoom GL through the mdev) -> **M-GL4** (60 fps, +no forcing) -> **M-GL5/M-GL6** (two VMs; video) - with gate definitions in +[`docs/04-implementation/05-graphics-execution-plan.md`](docs/04-implementation/05-graphics-execution-plan.md). +The current position is between M-GL1 and M-GL2: the execution machinery +runs (windows, MME macros, the DRAW), and pixels are the gate (see the +snapshot above). Both objectives are needed for the 1.0 mission; the CUDA +front is backgrounded while the graphics campaign holds the device. + **Status.** - **Emulation front: GREEN.** The driver-API smoke completes end-to-end @@ -621,11 +695,23 @@ isolation, performance, portability). can drive the host-owned device to an ECC Xid; shadowed BAR2 prevents it - committed and holding, no Xid since). Recurring and separate: guest-kernel boot panics (a NULL-in-interrupt/swap class) can kill a no-claim run at startup - - guest-side only, host stays healthy. A new host panic class was logged - 2026-10-05 11:18 with the (saved, reverted) pool-write-refusal experiment: a - sleeping VFIO mutex taken in atomic context in the sema GMMU walk plus a - vmalloc fatal exception in the bridge marshal path; reboot recovered the - host, no Xid. + guest-side only, host stays healthy. A new host panic class was logged + 2026-10-05 11:18 with the (saved, reverted) pool-write-refusal experiment: a + sleeping VFIO mutex taken in atomic context in the sema GMMU walk plus a + vmalloc fatal exception in the bridge marshal path; reboot recovered the + host, no Xid. +5. **Graphics execution (the GL campaign; current top front).** The engine + path now executes the direct client's stream (replay windows, MME macros, + the DRAW) with engine-authored stores, but three named gates remain: + (a) residual per-launch poison classes under the call/window-content + lottery (`0x2390` LCB, `0x2080` attr-prelude, `0x1614`; levers built and + in flight); (b) the raster/surface-binding blocker - draws retire without + storing to the X framebuffer, so render-target/surface binding is the + next gate; (c) the present/capture path once (b) lands. GATE1 (a + non-black frame with motion) is unmet; the app's FPS numbers are + fence-level completion, not rendering. Full context: the 2026-11-04 + snapshot above and + [`docs/04-implementation/05-graphics-execution-plan.md`](docs/04-implementation/05-graphics-execution-plan.md). ## Options to accelerate debugging toward end-to-end CUDA (candidate techniques; not directives) @@ -777,9 +863,11 @@ meant to execute on the physical GPU. | CUDA userspace: `cuInit`, `cuDeviceGetCount`, `cuDeviceGet` | ✅ | | `cuCtxCreate` returns | ✅ (the whole smoke test now completes) | | `cuMemAlloc` + `cuMemcpy` roundtrip (`ALL OK` in the smoke test) | ✅ payload roundtrip verified 64/64 in the guest | -| Full `nvidia-smi` output / kernel launch | 🟡 the static runtime initializes end-to-end with **real releases** and the launch now executes through the host bridge (see next row); a full `nvidia-smi` (per-process/utilization) remains unverified | -| CUDA kernel execution (`vectorAdd`) | ✅ **First green end-to-end guest CUDA (2026-10-04 ~16:20, no-claim host bridge):** `MAIL` + `VADD n=1048576 bad=0 checksum=392344090.500000` + `STATUS OK`, three consecutive deterministic supervised cycles, committed `cf6ff542`. The vadd runs through the host CUDA bridge daemon; forwarding guest engine work to the real GPU is the remaining backend path. | -| Graphics (3D), video | ❌ | +| Full `nvidia-smi` output / kernel launch | 🟡 the static runtime initializes end-to-end with **real releases**; a full `nvidia-smi` (per-process/utilization) remains unverified | +| CUDA kernel execution (`vectorAdd`) | ✅ **Guest CUDA executes on the physical GR engine (host bridge disabled, since 2026-10-14):** `victory_mail` `VADD bad=0` + `STATUS OK` and `vecadd_loop` 100 launches PASS; matmul/transformer green after the 2026-10-20 boot-lottery fix (`c72f8948`). Remaining red class: the D2H-stage data classes (release-discipline fixes staged); launch-latency robustness; then battery/soak/multi-tenant breadth. | +| Graphics execution - OpenGL/X on the emulated vGPU | 🟡 Xorg `:0` + `glxinfo` 4.6.0 (NVIDIA, direct rendering) + GZDoom launch are live; the direct GL client forms channels and submits; the engine executes the client's replay windows, MME macros and the DRAW (slot-34) with engine-authored stores - **no rasterised pixels yet** (every capture black). Ladder position: between M-GL1 and M-GL2. | +| Vulkan on the emulated vGPU | 🟡 the guest pipeline renders end-to-end but black; the inline-to-memory upload arm is the named gap; the SESSION 143 fence/completion regression is still open. | +| Video | 🟡 R18 CUDA-animation video on the emulated vGPU (60/60 frames, exact vs CPU math); two two-VM GZDoom videos (the GPU-accelerated one is the labelled virtio-gpu/virgl path, not the emulated vGPU). | | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ | Test status is tracked with the CUDA driver-API smoke test |