diff options
| -rw-r--r-- | STATE-CURRENT.md | 70 | ||||
| -rw-r--r-- | wiki/.publish-manifest.json | 110 | ||||
| -rw-r--r-- | wiki/Execution-Frontier.md | 57 | ||||
| -rw-r--r-- | wiki/Execution-Plane.md | 23 | ||||
| -rw-r--r-- | wiki/FAQ.md | 20 | ||||
| -rw-r--r-- | wiki/Graphics-Execution.md | 122 | ||||
| -rw-r--r-- | wiki/Host-Module.md | 13 | ||||
| -rw-r--r-- | wiki/OpenGL.md | 38 | ||||
| -rw-r--r-- | wiki/Physical-GPU-Backend.md | 13 | ||||
| -rw-r--r-- | wiki/Project-Goals.md | 6 | ||||
| -rw-r--r-- | wiki/Project-Plan.md | 26 | ||||
| -rw-r--r-- | wiki/Project-Status.md | 17 | ||||
| -rw-r--r-- | wiki/System-Overview.md | 24 |
13 files changed, 335 insertions, 204 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index b73d9b7..2fb0241 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,5 +1,64 @@ # Open-IOV Current State +> **Snapshot: 2026-11-14 ~10:55 (SESSION 157 continued; HEAD `339da842` == +> `vgpu/master`; working tree clean; supersedes the 2026-11-13 ~11:10 entry +> below).** +> The graphics front crossed the **push-delivery wall** and moved to **MME +> macro completion**. The direct-GL client's submission is now fully decoded: +> no client push carries a method-grammar draw header — its nine NV906F GPFIFO +> entries tile one contiguous buffer, and the per-frame work is carried as +> rewritten data-block blobs plus small real state pushes (324/476/728 B, head +> `90110087 80000800`) that invoke **MME macros** (the QMD-carrier hypothesis +> was tested and refuted: the entry format has no QMD bit, the blob is not a +> QMD, no QMD magic exists in 256 MiB BAR1). Delivery then landed: a +> content-gated FB-shadow rescue (`e1eac368`) and the LOW-band rescue +> (`b7f09616`) recover the recycled client pushes, the 324-B draw-state push +> opens a `C597` section, is captured and marked for the verbatim 3D lane +> (the first direct-GL stream3d marks), and with the golden MME overlay +> satisfying the prelude gate it **reaches the engine** (`GR LAUNCH submitted` +> + OK, MME-PRELUDE pack 1701 IR words, MME-GOLDEN slot 0 accepted). +> +> **The wall is the MME multi-part program gate.** The beef lane's 2799-word +> packed program cannot complete inside its <=2048-word block together with +> the 156-400-word draw window, so the load-only carrier gate drops every +> beef window (`MME-LOAD-ONLY carrier h=0xbeef0100 ... window=156 ... +> dropped`) and `live_gen` never promotes (completion launches end +> GP_GET-frozen / `MISSING_MACRO_DATA`+poison). A multi-part keep-window +> mechanism is committed default-off (`b44694b5`) and enabled in the campaign +> parameters (`339da842`); the A/B is pending. Two hypotheses were closed on +> the way: **RT routing** is not the store cause (the client clear targets RT0 +> while the window binds RT1; binding RT0 is verified 16x with correct +> target/geometry, yet 61/61 launches still `wrote=0`) and the **QMD carrier** +> theory is refuted; the `CODESRC` fault-park class is **prevented** +> (`17c7ed7c`: a suspect program page is relocated to the engine-mapped +> window-0 shadow, launch refused if mapping fails; one validated boot: 31 +> relocations, 51 GR launches, 79 GP_GET advances, 0 `FAULT_PDE`, 0 +> `WEDGE-REARM`, `backend_ok=35`, `fault=0`). +> +> **X start is now the throughput limiter.** The DDX/ScreenInit, USERD-latch, +> re-probe, kernel-mode-spin and flip-event walls stay fixed when X starts +> (validated >10-minute windows), but the first-generation start lottery is +> frequent: eng29-eng37 saw long dead-start stretches (X-DEAD, GLX-hung, +> ScreenInit-failed; 40+ dead starts in c374-c380, roughly 1/9 green), with +> one first-start green boot (c382) validating RT0 bind. `gl_frames` remains +> black (px0=0 x3 in c346, ~12-15 s/frame), `wrote=0`, and the off-screen +> mission stays held. +> +> CUDA front unchanged (backgrounded while graphics holds the device; its +> 10-30 status stands): `41343c63` green (`victory_mail` `VADD bad=0` + +> `STATUS OK`; `vecadd_loop` 100 launches PASS); the fresh-boot battery's +> red class is D2H-stage with release-discipline fixes staged; the SESSION +> 143 Vulkan fence regression is not re-measured. +> +> Live at check (read-only): host uptime 1 d 15 h (fresh boot 2026-11-12 +> ~19:16); `vgsp` loaded (refcount 1) + mdev +> `00dfe88e-0697-4aae-91fd-ddccfe584038` + QEMU cycle c402 (PID 241478, +> 12 GiB file-backed guest, kvmfr ivshmem, launched 10:50; X start 10:51); +> campaign knobs `partial_keep=N rt0=1 synth=Y grace=500`; `nvidia-smi` +> reports no GPU (the claim is held); pstore empty; no Xid/Oops; no reboot +> during the check. The open-iov.org wiki was refreshed alongside this +> snapshot (11 pages, revs 24144-24154; 68 pages audited, 0 problems). +> > **Snapshot: 2026-11-13 ~11:10 (SESSION 157 continued; HEAD `436cbf9d` == > `vgpu/master`; working tree carries one in-flight kernel file > (`M kernel/gsp_sema_service.c`, eng20 experiment); supersedes the @@ -812,11 +871,12 @@ no forcing) -> **M-GL5/M-GL6** (two VMs; video) - with gate definitions in The current position is between M-GL1 and M-GL2: the display and GL stacks now execute in the guest (NvKms registers, `/dev/dri`, X settles, `glxinfo` 4.6.0 direct, GZDoom obtains a real GL context), the off-screen GPU frame -path and the X/DDX stability walls are proven/closed, and captured GL sections -execute on the engine; the remaining gate is registration of the direct-GL -payload user/UVM VAS (setup/draw pushes still resolve to zero/implausible -PAs) plus the window/screen present before a rendered frame (see the snapshot -above). Both objectives are needed +path and the X/DDX stability walls are proven/closed, the direct-GL +submission is fully decoded (macro-driven), and the client's draw-state push +opens, captures and reaches the engine; the remaining gate is MME macro +completion (multi-part keep-window A/B pending) plus the window/screen +present before a rendered frame, with the X first-generation start lottery as +the throughput limiter (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. diff --git a/wiki/.publish-manifest.json b/wiki/.publish-manifest.json index 24a5be5..eb6b430 100644 --- a/wiki/.publish-manifest.json +++ b/wiki/.publish-manifest.json @@ -64,11 +64,11 @@ }, "FAQ": { "file": "FAQ.wiki", - "new_revid": 24138, - "old_revid": 24124, - "source_sha": "80d4a61ec210c032", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:12:01Z", + "new_revid": 24149, + "old_revid": 24138, + "source_sha": "e4f67b8e33bc3243", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:20Z", "title": "FAQ" }, "GMMU Multi-Tenant Protection": { @@ -127,11 +127,11 @@ }, "Graphics Execution": { "file": "Graphics-Execution.wiki", - "new_revid": 24134, - "old_revid": 24125, - "source_sha": "8da8637bb0987273", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:11:55Z", + "new_revid": 24145, + "old_revid": 24134, + "source_sha": "7270693e3ff2d8f8", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:14Z", "title": "Graphics Execution" }, "Guest Driver Lifecycle: A Field Guide": { @@ -226,11 +226,11 @@ }, "OpenGL": { "file": "OpenGL.wiki", - "new_revid": 24135, - "old_revid": 24127, - "source_sha": "05daf3eaa0974cd9", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:11:56Z", + "new_revid": 24146, + "old_revid": 24135, + "source_sha": "d7cf31994f4f175f", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:16Z", "title": "OpenGL" }, "Performance": { @@ -244,38 +244,38 @@ }, "Physical GPU Backend and Guest Wiring": { "file": "Physical-GPU-Backend.wiki", - "new_revid": 24140, - "old_revid": 24128, - "source_sha": "e371b8347739f412", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:12:04Z", + "new_revid": 24151, + "old_revid": 24140, + "source_sha": "21240b6fe98f105c", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:23Z", "title": "Physical GPU Backend and Guest Wiring" }, "Project Goals": { "file": "Project-Goals.wiki", - "new_revid": 24141, - "old_revid": 24129, - "source_sha": "e85b6ef4869f5837", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:12:05Z", + "new_revid": 24152, + "old_revid": 24141, + "source_sha": "b1ce8081b88564b4", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:25Z", "title": "Project Goals" }, "Project Plan": { "file": "Project-Plan.wiki", - "new_revid": 24142, - "old_revid": 24130, - "source_sha": "649625a12da890ce", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:12:07Z", + "new_revid": 24153, + "old_revid": 24142, + "source_sha": "0cb4313944736f12", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:26Z", "title": "Project Plan" }, "Project Status": { "file": "Project-Status.wiki", - "new_revid": 24133, - "old_revid": 24131, - "source_sha": "f60917535300a33e", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:11:53Z", + "new_revid": 24144, + "old_revid": 24133, + "source_sha": "4ac8dcb2cf7e27ff", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:13Z", "title": "Project Status" }, "RPC Message Format": { @@ -289,11 +289,11 @@ }, "System Overview": { "file": "System-Overview.wiki", - "new_revid": 24143, - "old_revid": 24132, - "source_sha": "0e395cbae9a0b86f", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:12:08Z", + "new_revid": 24154, + "old_revid": 24143, + "source_sha": "3c1d9ea91e55ad1d", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:27Z", "title": "System Overview" }, "Template:About message": { @@ -325,11 +325,11 @@ }, "The Execution Frontier": { "file": "Execution-Frontier.wiki", - "new_revid": 24136, - "old_revid": 24122, - "source_sha": "04c55fec2dda09b5", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:11:58Z", + "new_revid": 24147, + "old_revid": 24136, + "source_sha": "d20ea2d0fe872b06", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:17Z", "title": "The Execution Frontier" }, "The Guest Stack and CUDASW": { @@ -343,20 +343,20 @@ }, "The Host Module (vgsp.ko)": { "file": "Host-Module.wiki", - "new_revid": 24139, - "old_revid": 24126, - "source_sha": "6700460dbaa01a68", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:12:02Z", + "new_revid": 24150, + "old_revid": 24139, + "source_sha": "01db3c718be37c24", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:22Z", "title": "The Host Module (vgsp.ko)" }, "The vGSP Execution Plane (vEP)": { "file": "Execution-Plane.wiki", - "new_revid": 24137, - "old_revid": 24123, - "source_sha": "68edee8a9ca705d1", - "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall", - "timestamp": "2026-11-13T16:11:59Z", + "new_revid": 24148, + "old_revid": 24137, + "source_sha": "d9a53fc06056cb90", + "summary": "2026-11-14 status refresh: direct-GL submission decoded (macro-driven), push rescues land, draw-state push reaches the engine; MME multi-part completion is the wall; X start lottery is the limiter", + "timestamp": "2026-11-14T15:54:19Z", "title": "The vGSP Execution Plane (vEP)" }, "UVM in the Guest": { diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md index 5af5e6d..f24a15a 100644 --- a/wiki/Execution-Frontier.md +++ b/wiki/Execution-Frontier.md @@ -14,7 +14,7 @@ > [`../docs/04-implementation/03-execution-frontier.md`](../docs/04-implementation/03-execution-frontier.md); > the docs tree wins on disagreement. -Status: 2026-11-13, tree `master @ 436cbf9d`. +Status: 2026-11-14, tree `master @ 339da842`. Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories are labelled as such. @@ -107,16 +107,22 @@ non-black 640x480 frames per run and captured videos (45.4 s on 2026-11-11, a with its GL 4.6.0 context when the shared nvClip `modeNum` is even. The X side of the path was hardened in the 11-12/11-13 wave (DDX idle-DMA/ScreenInit, USERD-latch, re-probe, kernel-mode spin and flip-event walls closed; X green -for more than 10 minutes), captured GL sections now execute on the engine, and the -direct-GL push bodies decode as real GR method streams above 10 GiB through -the VAS walk. What is missing is **window/screen pixels through the NVIDIA -path**: the direct-GL payload VAs (`0x4001004` setup push, -`0x4250000`/`0x4250110` draws) still resolve to zero/implausible PAs because -their user/UVM VAS is never registered, so its draw sections never reach the -engine, glxgears' window is black, and a synchronous window draw wedges X on -some boots. The guest Vulkan pipeline's inline-to-memory upload arm is its -gap. The full picture lives on -[`Graphics-Execution.md`](Graphics-Execution.md). +for more than 10 minutes), captured GL sections now execute on the engine, and +the direct-GL submission is fully decoded: no client push carries a +method-grammar draw header — the work is macro-driven (data-block blobs plus +small state pushes invoking MME macros) — and the recycled pushes are now +recovered, so the client's draw-state push opens a `C597` section, captures, +and reaches the engine with the golden MME overlay. What is missing is +**window/screen pixels through the NVIDIA path**: the beef lane's 2799-word +packed MME program cannot complete inside its <=2048-word block with the +draw window, so `live_gen` never promotes and the draw never stores +(`wrote=0`, `px0=0`); the multi-part keep-window mechanism is committed +default-off with the A/B pending, RT routing was tested and refuted as the +cause, the `CODESRC` fault-park class is prevented, glxgears' window is +black, and a synchronous window draw wedges X on some boots. The X +first-generation start lottery is now the dominant throughput limiter. The +guest Vulkan pipeline's inline-to-memory upload arm is its gap. The full +picture lives on [`Graphics-Execution.md`](Graphics-Execution.md). No breadth beyond these is claimed: Windows guests, migration and performance numbers remain planned. @@ -178,14 +184,16 @@ fully green with glxinfo 4.6.0 and ~520 FPS glxgears, the DDX 3D replay executes, the X DDX/ScreenInit stability walls are closed with X green >10 minutes, captured GL sections execute on the engine, the first non-black GPU-rendered frames and videos are captured off-screen, and the direct-GL -ring/USERD machinery is substantially hardened); client push bodies now -decode as real GR method streams above 10 GiB via the VAS walk. The remaining -gap is registration: the direct-GL payload VAs (`0x4001004` setup push, -`0x4250000`/`0x4250110` draws) still resolve to zero/implausible PAs because -their user/UVM VAS is never registered, so its draw sections never open on -the engine, glxgears' window is black, and a window draw wedges X on some -boots. Command-stream delivery, the window/screen present and the X -first-generation screen-init lottery are the named blockers +ring/USERD machinery is substantially hardened); the direct-GL submission is +fully decoded (macro-driven; no method-grammar draw header in any push), the +recycled pushes are recovered, and the client's draw-state push opens, +captures and reaches the engine. The remaining gap is MME macro completion: +the beef lane's 2799-word packed program cannot complete inside its +<=2048-word block with the draw window, so `live_gen` never promotes and the +draw never stores (RT routing was tested and refuted as the cause; the +multi-part keep-window A/B is pending). glxgears' window is black, a window +draw wedges X on some boots, and the X first-generation start lottery is the +dominant throughput limiter ([`Graphics-Execution.md`](Graphics-Execution.md)). ## 6. Lines of investigation (live) @@ -200,11 +208,12 @@ first-generation screen-init lottery are the named blockers 4. **Hold the acceptance battery** — vector-add, matrix-multiply and the transformer kernel; each entry is accepted only on its own verification output (`bad=0` + `STATUS OK`). -5. **The graphics pixel frontier** — register the direct-GL payload user/UVM - VAS (or pin the payload set from the guest pagemap) so the setup push and - draw pushes resolve, make the window/screen present land, and reduce the X - first-generation screen-init lottery so the proven off-screen frames - become window pixels; the lanes, the walls and the milestone ladder are on +5. **The graphics pixel frontier** — land the MME multi-part keep-window A/B + so the beef macro program completes and `live_gen` promotes, verify the + store (`wrote>0`) at the bound render target, make the window/screen + present land, and reduce the X first-generation start lottery so the + proven off-screen frames become window pixels; the lanes, the walls and + the milestone ladder are on [`Graphics-Execution.md`](Graphics-Execution.md). ## 7. Theories, resolved diff --git a/wiki/Execution-Plane.md b/wiki/Execution-Plane.md index 4fa4b51..9c6909c 100644 --- a/wiki/Execution-Plane.md +++ b/wiki/Execution-Plane.md @@ -8,7 +8,7 @@ > when the two disagree, the docs tree wins. Front door: > [`../docs/README.md`](../docs/README.md). -Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` proven with the +Status: 2026-11-14, tree `master @ 339da842`. Tags: `[live]` proven with the stock guest driver; `[gated]` implemented, default-off or parameter-gated; `[wip]` partial; `[wall]` current blocker; `[target]` named success latch; `[planned]` designed, not built. @@ -157,15 +157,18 @@ guest: push + QMD + GPFIFO entry + doorbell (BAR0 0x88704) populated, the DDX 3D replay executes, the 2D path is green, the direct-GL ring/VAS and USERD machinery is hardened, and the first non-black GPU-rendered frames are proven (500/500 off-screen frames per run plus - captured 45.4 s and 50 s videos). Client push bodies decode as real GR - method streams above 10 GiB through the VAS walk (`436cbf9d`). No non-black - **window/screen** frame has been produced through the NVIDIA path yet: the - direct-GL payload VAs (setup push `0x4001004`, draws - `0x4250000`/`0x4250110`) still resolve to zero/implausible PAs because - their user/UVM VAS is never registered (so its draw sections never open), - glxgears' window is black, and X screen-init keeps a per-boot - first-generation lottery, so those are the named blockers. The lanes and - the ladder are on + captured 45.4 s and 50 s videos). The direct-GL submission is fully decoded + (no method-grammar draw header; the work is macro-driven — data-block blobs + plus small state pushes invoking MME macros), the recycled pushes are + recovered, and the client's draw-state push opens, captures and reaches the + engine (`GR LAUNCH submitted` + OK, golden MME overlay accepted). No + non-black **window/screen** frame has been produced through the NVIDIA path + yet: the MME macro program does not complete (the 2799-word packed program + cannot fit its <=2048-word block with the draw window, so `live_gen` never + promotes; the multi-part keep-window A/B is pending), RT routing was tested + and refuted as the cause, glxgears' window is black, and X start keeps a + per-boot first-generation lottery, so those are the named blockers. The + lanes and the ladder are on [`Graphics-Execution.md`](Graphics-Execution.md). ## 6. Portability diff --git a/wiki/FAQ.md b/wiki/FAQ.md index e357649..1a068c5 100644 --- a/wiki/FAQ.md +++ b/wiki/FAQ.md @@ -5,7 +5,7 @@ > [`../docs/09-reference/glossary-and-faq.md`](../docs/09-reference/glossary-and-faq.md); > the docs tree wins on disagreement. -Status: 2026-11-13, tree `master @ 436cbf9d`. +Status: 2026-11-14, tree `master @ 339da842`. ## Project and positioning @@ -48,13 +48,17 @@ frames per run, and videos were captured (45.4 s on 2026-11-11, 50 s on 2026-11-12). GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context on an even modeNum. The X DDX idle-DMA/ScreenInit, USERD-latch, re-probe, kernel-mode-spin and flip-event walls were closed (X green >10 -minutes), captured GL sections now execute on the engine, and the client's -push bodies decode as real GR method streams above 10 GiB. Window and screen -pixels are still the wall: the direct-GL payload VAs (the `0x4001004` setup -push and the `0x4250000`/`0x4250110` draws) resolve to zero/implausible PAs -because their user/UVM VAS is never registered, so its draws never reach the -engine; glxgears' window is black, and X screen-init keeps a per-boot -first-generation lottery. The guest Vulkan pipeline runs end to end (device +minutes), captured GL sections now execute on the engine, and the direct-GL +submission is fully decoded: it carries no classic draw header (the work is +macro-driven; data-block blobs plus small state pushes invoking MME macros), +the recycled pushes are recovered, and the client's draw-state push opens, +captures and reaches the engine. Window and screen pixels are still the wall: +the MME macro program does not complete (the 2799-word packed program cannot +fit its <=2048-word block with the draw window, so `live_gen` never promotes +and the draw never stores; the multi-part keep-window A/B is pending), RT +routing was tested and refuted as the cause, glxgears' window is black, and X +start keeps a per-boot first-generation lottery. The guest Vulkan pipeline +runs end to end (device → command buffer → fence → readback) but frames are black. See [`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) and [`Graphics-Execution.md`](Graphics-Execution.md). diff --git a/wiki/Graphics-Execution.md b/wiki/Graphics-Execution.md index 107044c..7879505 100644 --- a/wiki/Graphics-Execution.md +++ b/wiki/Graphics-Execution.md @@ -12,7 +12,7 @@ > [`../docs/04-implementation/04-real-render-walls.md`](../docs/04-implementation/04-real-render-walls.md) > (the measured walls); the docs tree wins on disagreement. -Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` observed end to +Status: 2026-11-14, tree `master @ 339da842`. Tags: `[live]` observed end to end; `[wip]` partially built; `[wall]` current blocker; `[target]` defined success state; `[planned]` designed, not built. @@ -95,15 +95,31 @@ fidelity: kernel-mode spin (a display-engine GET-past-PUT on a driver ring wrap) and the flip-event timeout are all fixed, and captured GL sections now execute on the engine (`GR LAUNCH submitted` / `GUEST GR LAUNCH OK`) with - the data window populated (`n_data` 0 -> 1024). What remains for the - client's own stream is **delivery**: the lookalike gate and the live-PA - bound fix (10 GiB raised to the registered guest-RAM top, 14 GiB) let the - client's 13+ GiB page directories walk and decode real GR method streams - (impossible before), but the GL setup push (59,556 bytes at VA `0x4001004`) - and the draw pushes (`0x4250000`/`0x4250110`) still resolve to - zero/implausible PAs because their user/UVM VAS is never registered, so no - draw section opens for `0xbeef0100` and the window stays black; - window/screen present is still the frontier (§6). + the data window populated (`n_data` 0 -> 1024). The direct-GL client's + submission is now **fully decoded**: no client push carries a + method-grammar draw header — its nine NV906F GPFIFO entries tile one + contiguous buffer and its per-frame work is carried as rewritten + data-block blobs plus small real state pushes (324/476/728 B, head + `90110087 80000800`) that invoke MME macros (the QMD-carrier hypothesis was + tested and refuted: the entry format has no QMD bit, the blob is not a QMD, + and no QMD magic exists in the 256 MiB BAR1). Delivery into the lane then + landed: a content-gated FB-shadow rescue (`e1eac368`) and the LOW-band + rescue (`b7f09616`) recover the recycled client pushes, the 324-B + draw-state push opens a `C597` section, is captured and marked for the + verbatim 3D lane (the first direct-GL stream3d marks), and with the golden + MME overlay satisfying the prelude gate it **reaches the engine** + (`GR LAUNCH submitted` + OK, MME-PRELUDE pack 1701 IR words, MME-GOLDEN + slot 0 accepted). The current wall is **MME macro completion**: the beef + lane's 2799-word packed program cannot complete inside its <=2048-word + block together with the 156-400-word draw window, so the load-only carrier + gate drops every beef window and `live_gen` never promotes; a multi-part + keep-window mechanism is committed default-off (`b44694b5`) and enabled in + the campaign parameters (`339da842`), with the A/B pending. RT routing was + tested and refuted as the store cause (RT0 bind verified 16x, still + `wrote=0`), and the `CODESRC` fault-park class is prevented (a suspect + program page is relocated to the engine-mapped window-0 shadow; + `17c7ed7c`). The window stays black; the window/screen present is still the + frontier (§6). ## 4. The channel and object picture @@ -162,9 +178,9 @@ swaps, and the GR backend no longer times out (the pair-close/pair-safe frames and captured videos (45.4 s and 50 s), the RM write-lock holder (Xorg in the DDX vidheap scrub wait) is fixed (`df6e71bb`), the X DDX/ScreenInit stability walls are closed, and the direct-GL ring/USERD - machinery is hardened. The next step is delivering the direct-GL payload - (setup push at VA `0x4001004`, draws at `0x4250000`/`0x4250110`) by - registering its user/UVM VAS, and then the window/screen present path. + machinery is hardened. The next step is completing the direct-GL MME + macro program (multi-part keep-window A/B), then the window/screen present + path. During bring-up the module also carries a **diagnostics-only mirror** for apps that spin on a shared progress word; it exists so a run can proceed while the @@ -173,23 +189,31 @@ requires it switched off, along with any external poke. ## 6. Where the frontier is (ranked walls) -1. **Direct-GL command-stream delivery** `[wall]`. The ring/VAS anchor, the - lookalike gate (a dense repeating-pointer page is refused) and the live-PA - bound are now right: the bound was raised from a compile-time 10 GiB to the - registered guest-RAM top (14 GiB on the 12 GiB boots), so the client's - parked page directory at 13+ GiB walks and push bodies decode as **real GR - method streams** (`src=4 plausible=1`, e.g. `SET_SUBDEVICE_MASK` + - `LAUNCH_DMA`) — reads that were impossible before. The exact remaining gap - is registration: the GL setup push (59,556 bytes at VA `0x4001004`) and the - draw pushes (`0x4250000`/`0x4250110`) still resolve to zero/implausible - PAs, and a walk probe during `gl_frames` shows **no registered VAS maps - them** — the payloads live in the client's user/UVM VAS, which the service - never registers. Until that VAS is registered (or the payload set pinned - from the guest pagemap), no GL draw section opens for `0xbeef0100` and the - window stays black. Related finding: the engine-zero-write campaign showed - the store wall is upstream of the draw — the replayed 221-word window - contains no draw, and the front end was parking on a pre-poisoned CWD only - because of that (the CWD-clear fixes landed as hygiene, not as the cause). +1. **Direct-GL MME macro completion** `[wall]`. Delivery to the lane is no + longer the gap: the submission is fully decoded (nine NV906F entries tile + one contiguous buffer; no method-grammar draw header exists; the per-frame + work is data-block blobs plus real state pushes that invoke MME macros), + the recycled pushes are recovered by the content-gated FB-shadow and + LOW-band rescues, the client's 324-B draw-state push opens a `C597` + section, is captured and marked for the verbatim 3D lane, and reaches the + engine with the golden MME overlay (`GR LAUNCH submitted` + OK, + MME-PRELUDE pack 1701 IR words, MME-GOLDEN slot 0 accepted). The wall is + the multi-part program gate: the beef lane's 2799-word packed MME program + cannot complete inside a <=2048-word block together with its 156-400-word + draw window, so the load-only carrier gate drops each beef window + (`MME-LOAD-ONLY carrier ... window=156 ... dropped`) and `live_gen` never + promotes. A multi-part keep-window mechanism is committed default-off + (`b44694b5`) and enabled in the campaign parameters (`339da842`); the A/B + is pending. Two hypotheses were closed on the way: the QMD-carrier theory + (refuted: the entry format has no QMD bit, the blob is not a QMD, no QMD + magic in 256 MiB BAR1) and RT routing (the clear targets RT0 while the + window binds RT1; binding RT0 is verified 16x with correct target/geometry + but the store still misses, 61/61 `wrote=0`) — the store wall is macro/ + front-end execution, not reachability. Related reliability result: the + `CODESRC` fault-park class is prevented by relocating a suspect program + page to the engine-mapped window-0 shadow (`17c7ed7c`; one validated boot: + 31 relocations, 51 GR launches, 79 GP_GET advances, 0 `FAULT_PDE`, 0 + `WEDGE-REARM`, `backend_ok=35`). 2. **Window/screen present** `[wall]`. The pbuffer and off-screen frame paths are proven (`pixel=ff0000ff`, 500/500 non-black frames, captured videos), but a windowed present does not land: glxgears' window is black, the DDX @@ -201,12 +225,15 @@ requires it switched off, along with any external poke. the post-ScreenInit Xorg kernel-mode spin (display-engine GET-past-PUT on a driver ring wrap) and the flip-event timeout are fixed, and X has stayed green for >10 minutes in a validated window. What remains is a per-boot - **first-generation lottery**: only an X started immediately after boot - passes the DDX DMA init (3/7 windows), later DMA instances can still fail, - and the shared nvClip `modeNum` must be even for the GL client's state init - (an odd value is guest userspace X-driver state, cleared by one X restart — - not a host bug). Wrapped PUTs and the kick-idle marker/GET publication are - handled; a guest kernel panic after a wedge is recovered by an offline + **first-generation lottery** that became the dominant throughput limiter + for the graphics A/B runs: only an X started immediately after boot passes + the DDX DMA init (3/7 windows in one runoff; long dead-start stretches + later, with one green first-start boot, c382), later DMA instances can + still fail, and the shared nvClip `modeNum` must be even for the GL + client's state init (an odd value is guest userspace X-driver state, + cleared by one X restart — not a host bug). Wrapped PUTs and the kick-idle + marker/GET publication are handled; a guest kernel panic after a wedge is + recovered by an offline filesystem check. 4. **Non-black window frames and sustained rate** `[wall]`/`[target]`. Once the command-stream delivery, the window/screen present and X screen-init @@ -241,15 +268,20 @@ requires it switched off, along with any external poke. | X DDX idle-DMA/ScreenInit, USERD-latch lifetime, re-probe thrash, Xorg kernel-mode spin (GET-past-PUT) and flip-event walls closed; X green for >10 minutes (`13a0c5d6`, `acb51d53`, `6ebc7cd4`, `770d6b4a`, `b9213c57`, `29690635`) | `[live]` | | Captured GL sections execute on the engine (`GR LAUNCH submitted` / `GUEST GR LAUNCH OK`); data window populated (`n_data` 0 -> 1024) | `[live]` | | Client push bodies decode as real GR method streams above 10 GiB through the VAS walk (live-PA bound raised to the registered guest-RAM top, `436cbf9d`; lookalike gate `7d27df77`) | `[live]` | +| Direct-GL submission fully decoded: nine NV906F entries tile one contiguous buffer; no method-grammar draw header in any push; per-frame work is data-block blobs + real state pushes (324/476/728 B) invoking MME macros; QMD-carrier hypothesis refuted | `[live]` | +| Recycled direct-GL pushes recovered (content-gated FB-shadow rescue `e1eac368`, LOW-band rescue `b7f09616`); client draw-state push opens a `C597` section, captures and is marked for the verbatim 3D lane | `[live]` | +| Direct-GL state push reaches the engine with the golden MME overlay (`GR LAUNCH submitted` + OK; MME-PRELUDE pack 1701 IR words; MME-GOLDEN slot 0 accepted) | `[live]` | +| `CODESRC` fault-park class prevented: suspect program page relocated to the engine-mapped window-0 shadow (`17c7ed7c`; validated boot 31 relocations, 51 GR launches, 79 GP_GET advances, 0 `FAULT_PDE`, 0 `WEDGE-REARM`, `backend_ok=35`) | `[live]` | +| RT routing tested and refuted as the store cause: RT0 bind verified 16x with correct target/geometry, still 61/61 `wrote=0` | `[live]` (negative result) | | GZDoom passes `V_Init: allocate screen` with GL 4.6.0 when shared nvClip `modeNum` is even | `[live]` | | RM write-lock holder identified (Xorg in the DDX vidheap scrub wait) and fixed (`df6e71bb`) | `[live]` | | GL section capture: the X channel's `0xC597` stream decoded | `[live]` | | Verbatim 3D method-stream replay retired by the engine (no MMU fault) | `[live]` | | Synthesized launch executes real `sm_75` SASS; Turing `V3` program header accepted | `[live]` | | Emulated FB/GART sizing traps fixed (FB info replies in KB; GART default 256 MiB), removing the 4 GiB guest-allocation class | `[live]` | -| Direct-GL command-stream delivery (gl setup push at VA `0x4001004` and draws at `0x4250000`/`0x4250110`; the CE ring `0xbeef0101`) | `[wall]` — the payloads' user/UVM VAS is never registered, so they resolve to zero/implausible PAs and no section opens for `0xbeef0100` | +| Direct-GL MME macro completion (multi-part keep-window: the 2799-word packed program + 156-400-word draw window cannot fit the <=2048-word block; `live_gen` never promotes) | `[wall]` — mechanism committed `b44694b5` (default off) and enabled in params (`339da842`); A/B pending | | Window/screen present produces non-black window pixels | `[wall]` | -| X screen-init first-generation lottery (`modeNum` parity; only an immediately-post-boot X passes DDX DMA init) | `[wip]` | +| X screen-init first-generation lottery (`modeNum` parity; only an immediately-post-boot X passes DDX DMA init; dominant throughput limiter) | `[wip]` | | Non-black screen pixels from the emulated vGPU's 3D pipeline | `[wall]` | | Windows/DirectX guests | `[planned]` | @@ -263,12 +295,14 @@ requires it switched off, along with any external poke. * Display/KMS bring-up (NvKms, `/dev/dri`, X, a real GL context) is not a rendered-frame claim. GZDoom reaching `V_Init: allocate screen` proves the client's GL init and the direct-GL GR lane, not the game loop or a - presented frame; the direct-GL payload VAS is not registered, so the - client's draws do not reach the engine. -* The engine-zero-write (NOWRITE) campaign is not a rendering result: it - proved the replay window it inspected carried no draw, and that the front - end was parking on a pre-poisoned CWD only as a consequence; the store wall - is upstream in push delivery, not a 3D-pipeline defect. + presented frame; the client's draw-state push reaches the engine, but the + MME macro program does not complete, so its draws do not store and the + window stays black. +* The engine-zero-write (NOWRITE) campaign is not a rendering result: it and + the draw census together proved the submission is macro-driven (no + method-grammar draw header exists), that RT routing is not the cause, and + that the store wall is macro/front-end execution; they are measurements of + the wall, not a 3D-pipeline defect or a pixels claim. * No frame-rate or latency numbers: the scheduled measurement is defined (60 fps over 60 s, no forcing) but not yet met. diff --git a/wiki/Host-Module.md b/wiki/Host-Module.md index 651b1bd..6eebeaf 100644 --- a/wiki/Host-Module.md +++ b/wiki/Host-Module.md @@ -6,7 +6,7 @@ > source: [`../docs/03-architecture/06-host-module-and-hybrid-model.md`](../docs/03-architecture/06-host-module-and-hybrid-model.md); > the docs tree wins on disagreement with this page. > -> Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` observed with +> Status: 2026-11-14, tree `master @ 339da842`. Tags: `[live]` observed with > the stock guest driver; `[wip]` demonstrated live, being productized; > `[gated]` implemented default-off behind supervised gates; `[wall]` known > blocking limit; `[target]` designed, not built; `[planned]` roadmap. @@ -133,10 +133,13 @@ write-lock holder (Xorg in the DDX vidheap scrub wait) is fixed ~520 FPS `glxgears`), the X DDX/ScreenInit stability walls are closed (X green >10 minutes), and the direct-GL ring/VAS and USERD machinery is hardened (verified page-directory discovery, eager push pins, -client-allocated USERD resolution, foreign-USERD skip). The remaining GL gap -is delivery of the direct-GL payload (setup push at VA `0x4001004`, draws at -`0x4250000`/`0x4250110` — their user/UVM VAS is never registered, so they -resolve to zero/implausible PAs) and the window/screen present path, which +client-allocated USERD resolution, foreign-USERD skip). The direct-GL +submission is fully decoded (macro-driven; no classic draw header), the +recycled pushes are recovered by the content-gated FB-shadow and LOW-band +rescues, and the client's draw-state push opens, captures and reaches the +engine with the golden MME overlay. The remaining GL gap is MME macro +completion (the packed program cannot fit its block with the draw window; +multi-part keep-window A/B pending) and the window/screen present path, which currently stays black or wedges X. ## 6. Debug parameters diff --git a/wiki/OpenGL.md b/wiki/OpenGL.md index e9a1750..b647eef 100644 --- a/wiki/OpenGL.md +++ b/wiki/OpenGL.md @@ -12,7 +12,7 @@ > [`../docs/03-architecture/02-guest-stack-and-cudasw.md`](../docs/03-architecture/02-guest-stack-and-cudasw.md) > (the guest stack). The docs tree wins on disagreement. -Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` observed with the +Status: 2026-11-14, tree `master @ 339da842`. Tags: `[live]` observed with the stock guest driver; `[wip]` partial; `[wall]` current blocker; `[target]` defined success state. @@ -89,14 +89,19 @@ Rated honestly, against the milestone ladder in the plan: | X DDX idle-DMA/ScreenInit, USERD-latch lifetime, re-probe thrash, Xorg kernel-mode spin (GET-past-PUT) and flip-event walls closed; X green >10 minutes (`13a0c5d6`, `acb51d53`, `6ebc7cd4`, `770d6b4a`, `b9213c57`, `29690635`) | `[live]` | | Captured GL sections execute on the engine (`GR LAUNCH submitted` / `GUEST GR LAUNCH OK`); data window populated (`n_data` 0 -> 1024) | `[live]` | | Client push bodies decode as real GR method streams above 10 GiB via the VAS walk (live-PA bound raised to the registered guest-RAM top, `436cbf9d`) | `[live]` | +| Direct-GL submission fully decoded: nine NV906F entries tile one contiguous buffer; no method-grammar draw header; per-frame work is data-block blobs + real state pushes (324/476/728 B) invoking MME macros; QMD-carrier hypothesis refuted | `[live]` | +| Recycled direct-GL pushes recovered (content-gated FB-shadow rescue `e1eac368`, LOW-band rescue `b7f09616`); the 324-B draw-state push opens a `C597` section, captures and is marked for the verbatim 3D lane | `[live]` | +| Direct-GL state push reaches the engine with the golden MME overlay (`GR LAUNCH submitted` + OK; MME-PRELUDE pack 1701 IR words; MME-GOLDEN slot 0 accepted) | `[live]` | +| `CODESRC` fault-park class prevented (program page relocated to the engine-mapped window-0 shadow, `17c7ed7c`; validated boot 31 relocations, 51 GR launches, 79 GP_GET advances, 0 `FAULT_PDE`, 0 `WEDGE-REARM`, `backend_ok=35`) | `[live]` | +| RT routing tested and refuted as the store cause: RT0 bind verified 16x with correct target/geometry, still 61/61 `wrote=0` | `[live]` (negative result) | | GZDoom passes `V_Init: allocate screen` with GL 4.6.0 when shared nvClip `modeNum` is even | `[live]` | | RM write-lock holder identified (Xorg in the DDX vidheap scrub wait) and fixed (`df6e71bb`) | `[live]` | | Engine executes a launch built from the captured section (real `sm_75` SASS retired) | `[live]` | | Verbatim 3D method-stream replay retired by the engine, no MMU fault | `[live]` | | Emulated FB/GART sizing traps fixed (FB info replies in KB; GART default 256 MiB), removing the 4 GiB guest-allocation class | `[live]` | -| Direct-GL command-stream delivery (gl setup push at VA `0x4001004` and draws at `0x4250000`/`0x4250110`; the CE ring `0xbeef0101`) | `[wall]` — the payloads' user/UVM VAS is never registered; they resolve to zero/implausible PAs and no section opens for `0xbeef0100` | +| Direct-GL MME macro completion (multi-part keep-window: 2799-word packed program + 156-400-word draw window cannot fit the <=2048-word block; `live_gen` never promotes) | `[wall]` — mechanism committed `b44694b5` (default off) and enabled in params (`339da842`); A/B pending | | Window/screen present produces non-black screen pixels | `[wall]` | -| X screen-init first-generation lottery (`modeNum` parity; only an immediately-post-boot X passes DDX DMA init) | `[wip]` | +| X screen-init first-generation lottery (`modeNum` parity; only an immediately-post-boot X passes DDX DMA init; dominant throughput limiter) | `[wip]` | | 60 fps sustained, no forcing (M-GL4) | `[target]` | ## 4. How OpenGL runs are verified @@ -121,14 +126,18 @@ X and the stock GLX path are fully green (`glxinfo -B` rc 0, ~520 FPS `glxgears`, Xorg WAIT 0), the DDX/X-stability walls were closed (X green for more than 10 minutes), the direct-GL ring/USERD machinery is hardened, and the GPU-rendered pbuffer path produced non-black animated frames and captured -videos (45.4 s and 50 s). Captured GL sections now execute on the engine and -the client's push bodies decode as real GR method streams above 10 GiB. The -remaining gates are **delivery of the direct-GL client's own command stream** -(the setup push at `0x4001004` and the draws at `0x4250000`/`0x4250110` still -resolve to zero/implausible PAs because their user/UVM VAS is never -registered), the window/screen present path (glxgears' window is black and a -window draw can wedge X), and the X first-generation screen-init lottery — -then the first rendered screen frame. +videos (45.4 s and 50 s). Captured GL sections now execute on the engine, and +the direct-GL client's submission is fully decoded: it carries no classic +draw header — the work is macro-driven (data-block blobs plus small state +pushes invoking MME macros), the recycled pushes are recovered, and the +client's draw-state push opens, captures and reaches the engine. The +remaining gates are **MME macro completion** (the 2799-word packed program +cannot complete inside its <=2048-word block with the 156-400-word draw +window, so `live_gen` never promotes; the multi-part keep-window mechanism is +committed default-off and enabled for the pending A/B), the window/screen +present path (glxgears' window is black and a window draw can wedge X), and +the X first-generation screen-init lottery — then the first rendered screen +frame. ## 6. What is not claimed @@ -136,9 +145,10 @@ then the first rendered screen frame. vGPU yet; every screen capture so far is black. The non-black frames and the videos (45.4 s and 50 s) come from the off-screen pbuffer path (pbuffer -> sysmem -> kvmfr ivshmem -> host reader), not from a windowed X screen - capture. The direct-GL payload VAS is not registered, its draws do not reach - the engine, a synchronous window draw wedges X, and X screen-init retains a - per-boot first-generation lottery. Those are the current walls. + capture. The client's draw-state push now reaches the engine, but the MME + macro program does not complete so the draw never stores, a synchronous + window draw wedges X, and X start retains a per-boot first-generation + lottery. Those are the current walls. * GZDoom reaching `V_Init: allocate screen` is not a rendered-frame claim; it proves the client's GL init and the direct-GL GR lane, not the game loop or a presented frame. diff --git a/wiki/Physical-GPU-Backend.md b/wiki/Physical-GPU-Backend.md index 1f82bdf..9b4a88f 100644 --- a/wiki/Physical-GPU-Backend.md +++ b/wiki/Physical-GPU-Backend.md @@ -5,7 +5,7 @@ > guest-facing emulation. Canonical sources: [`../docs/03-architecture/08-physical-gpu-integration.md`](../docs/03-architecture/08-physical-gpu-integration.md) > and [`../docs/03-architecture/11-physical-backend-guest-wiring.md`](../docs/03-architecture/11-physical-backend-guest-wiring.md); the docs tree wins on disagreement. -Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` proven with the +Status: 2026-11-14, tree `master @ 339da842`. Tags: `[live]` proven with the stock guest driver; `[gated]` implemented default-off; `[wip]` partially built; `[wall]` current blocker; `[target]` planned end state. @@ -109,7 +109,7 @@ FAIL a failed mutating operation parks the device in a locked fail-safe; | Host RM client and first real engine work (static config, real objects, 4 KiB CE copy) | done `[live]` | | Guest-copy forwarding, deferred release, hardware-primary copies, engine-authored relay, fault relay | verified live (seams parameterised and fail-open); the staged-transfer class is under repair `[live]` | | CUDA kernel execution (`vectorAdd` and further clients) | done `[live]` — stock guest CUDA clients (vector-add, matrix-multiply, transformer) execute on the physical engine with verified results and engine-authored completions relayed to the guest | -| Graphics method-stream execution (verbatim 3D replay, synthesized launches, direct-GL client channels) | `[wip]` — the engine retires real graphics streams, the display/KMS stack registers and X + stock GLX are green (the DDX/ScreenInit stability walls are closed, X green >10 minutes), captured GL sections execute, and the first non-black GPU-rendered frames are captured off-screen; registration of the direct-GL payload user/UVM VAS (setup/draw pushes still resolve to zero/implausible PAs) and the window/screen present are the frontier ([`Graphics-Execution.md`](Graphics-Execution.md)) | +| Graphics method-stream execution (verbatim 3D replay, synthesized launches, direct-GL client channels) | `[wip]` — the engine retires real graphics streams, the display/KMS stack registers and X + stock GLX are green (the DDX/ScreenInit stability walls are closed, X green >10 minutes), captured GL sections execute, the direct-GL submission is fully decoded (macro-driven, no classic draw header), the client's draw-state push reaches the engine, and the first non-black GPU-rendered frames are captured off-screen; MME macro completion (multi-part keep-window A/B pending) and the window/screen present are the frontier ([`Graphics-Execution.md`](Graphics-Execution.md)) | ## 7. The execution frontier @@ -128,10 +128,11 @@ kernel-mode-spin and flip-event walls are closed, X green >10 minutes), X and the stock GLX path are fully green (`glxinfo -B` rc 0, ~520 FPS `glxgears`), the DDX 3D replay executes, captured GL sections execute on the engine, and the first non-black GPU-rendered frames are proven (500/500 off-screen frames -per run plus captured videos); the remaining graphics gates are registration -of the direct-GL payload user/UVM VAS (setup/draw pushes still resolve to -zero/implausible PAs), the window/screen present, and the X first-generation -screen-init lottery before non-black window pixels. The remaining +per run plus captured videos); the direct-GL submission is fully decoded +(macro-driven) and its draw-state push reaches the engine, so the remaining +graphics gates are MME macro completion (multi-part keep-window A/B pending), +the window/screen present, and the X first-generation start lottery before +non-black window pixels. The remaining compute work is the staged-transfer class (under repair), the every-boot acceptance campaign, and per-guest execution isolation — see [`Execution-Frontier.md`](Execution-Frontier.md) and diff --git a/wiki/Project-Goals.md b/wiki/Project-Goals.md index 5222947..39eb1be 100644 --- a/wiki/Project-Goals.md +++ b/wiki/Project-Goals.md @@ -10,7 +10,7 @@ > [`Execution-Frontier.md`](Execution-Frontier.md) and > [`Graphics-Execution.md`](Graphics-Execution.md). -Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` working with the +Status: 2026-11-14, tree `master @ 339da842`. Tags: `[live]` working with the stock guest driver; `[wip]` in progress; `[planned]` designed, not built; `[target]` bring-up ahead; `[non-goal]` explicitly out of scope. @@ -46,12 +46,12 @@ drivers, no license.** ## 3. Goals and their status -| Goal | What success looks like | Status (2026-11-13) | +| Goal | What success looks like | Status (2026-11-14) | |---|---|---| | Stock guest driver initialisation | The unmodified driver probes, initialises and enumerates as on bare metal (`nvidia-smi`) | `[live]` — TU104 reference platform | | Full CUDA driver-API surface | Context creation, allocation, copies, free, destroy complete with correct results | `[live]` — the driver-API smoke prints `ALL OK`; the 64-byte payload round-trips | | CUDA kernel execution on real hardware | Verified guest kernels execute on the physical GPU, with engine-authored completions waking the guest | `[live]` — vector-add, matrix-multiply and transformer clients green on fresh boots; the staged-transfer class, the every-boot acceptance campaign and per-guest isolation are in progress ([`Execution-Frontier.md`](Execution-Frontier.md)) | -| OpenGL (3D graphics) | Stock guest GL applications render real pixels through the emulated vGPU | `[wip]` — the display/KMS stack and X run, the stock NVIDIA GLX path is fully green (`glxinfo -B` rc 0, OpenGL 4.6.0 direct, `glxgears` ~520 FPS), the 2D path is green, the DDX 3D replay executes, the X DDX/ScreenInit stability walls are closed (X green >10 minutes), captured GL sections execute on the engine, and the first non-black GPU-rendered frames plus captured videos (45.4 s and 50 s) are proven off-screen; GZDoom reaches `V_Init`. Window/screen pixels remain the frontier: the direct-GL payload VAs (setup push `0x4001004`, draws `0x4250000`/`0x4250110`) resolve to zero/implausible PAs because their user/UVM VAS is never registered, so its draws never reach the engine; the window/screen present is unproven, and X screen-init keeps a first-generation lottery ([`OpenGL.md`](OpenGL.md)) | +| OpenGL (3D graphics) | Stock guest GL applications render real pixels through the emulated vGPU | `[wip]` — the display/KMS stack and X run, the stock NVIDIA GLX path is fully green (`glxinfo -B` rc 0, OpenGL 4.6.0 direct, `glxgears` ~520 FPS), the 2D path is green, the DDX 3D replay executes, the X DDX/ScreenInit stability walls are closed (X green >10 minutes), captured GL sections execute on the engine, the direct-GL submission is fully decoded (macro-driven, no classic draw header), the client's draw-state push reaches the engine, and the first non-black GPU-rendered frames plus captured videos (45.4 s and 50 s) are proven off-screen; GZDoom reaches `V_Init`. Window/screen pixels remain the frontier: the MME macro program does not complete (multi-part keep-window A/B pending), RT routing was refuted as the cause, the store still misses (`wrote=0`), the window/screen present is unproven, and X start keeps a first-generation lottery ([`OpenGL.md`](OpenGL.md)) | | Vulkan | Stock guest Vulkan applications render real pixels | `[wip]` — the pipeline runs end to end (device → command buffer → fence → readback); frames are black — program delivery and program-VA mapping are the frontier ([`Vulkan.md`](Vulkan.md)) | | Windows guests (DirectX, CUDA) | A stock WDDM driver and stock D3D/CUDA applications run in Windows guests | `[target]` — not started; same emulation target ([`DirectX.md`](DirectX.md)) | | Video (NVENC/NVDEC) | Encode/decode through the emulated device | `[planned]` | diff --git a/wiki/Project-Plan.md b/wiki/Project-Plan.md index 0300b78..3d10d8d 100644 --- a/wiki/Project-Plan.md +++ b/wiki/Project-Plan.md @@ -15,7 +15,7 @@ > [`../docs/06-portability/03-device-validation-and-porting-sequence.md`](../docs/06-portability/03-device-validation-and-porting-sequence.md); > the docs tree wins on disagreement. -Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[done]`, `[active]`, +Status: 2026-11-14, tree `master @ 339da842`. Tags: `[done]`, `[active]`, `[ahead]` — the plan's own state vocabulary, distinct from the goal tags. ## 1. How the plan works @@ -40,11 +40,11 @@ itself: ## 2. The phases -| Phase | What it delivers | Exit gate | State (2026-11-13) | +| Phase | What it delivers | Exit gate | State (2026-11-14) | |---|---|---|---| | **P0 — Platform** | Emulated vGPU device, GSP boot and GSP-RM emulation, stock guest driver initialisation | Driver-API smoke green (`ALL OK`) = evaluation rung 2 | `[done]` | | **P1 — First execution (compute)** | Guest CUDA kernels executing on the physical GPU, with engine-authored completions; then hardening | Verified clients + engine-authored completion = rung 3 core; hardening: staged-transfer class, every-boot acceptance, per-guest isolation | `[active]` — execution green; hardening in progress | -| **P2 — Graphics execution** | OpenGL/Vulkan draw commands executed by the physical 3D pipeline and delivered as readable pixels | The graphics ladder: M-GL1 client context-init executes; M-GL2 `glxgears` non-black; M-GL3 GZDoom GL non-black through the mdev | `[active]` — between M-GL1 and M-GL2 with M-GL2's off-screen half proven: the display/KMS and DDX replay machinery work, X + stock GLX are green, the first non-black GPU-rendered frames and videos are captured, the X DDX/ScreenInit stability walls are closed, captured GL sections execute on the engine, and direct-GL push bodies decode above 10 GiB; the remaining walls are registration of the direct-GL payload user/UVM VAS (setup/draw pushes still resolve to zero/implausible PAs), the window/screen present, and the X first-generation screen-init lottery | +| **P2 — Graphics execution** | OpenGL/Vulkan draw commands executed by the physical 3D pipeline and delivered as readable pixels | The graphics ladder: M-GL1 client context-init executes; M-GL2 `glxgears` non-black; M-GL3 GZDoom GL non-black through the mdev | `[active]` — between M-GL1 and M-GL2 with M-GL2's off-screen half proven: the display/KMS and DDX replay machinery work, X + stock GLX are green, the first non-black GPU-rendered frames and videos are captured, the X DDX/ScreenInit stability walls are closed, captured GL sections execute on the engine, the direct-GL submission is fully decoded (macro-driven, no classic draw header), and the client's draw-state push now reaches the engine; the remaining walls are MME macro completion (multi-part keep-window A/B pending), the window/screen present, and the X first-generation start lottery | | **P3 — Sustained and multi-tenant** | Frame rates without assistance; multiple VMs sharing the GPU with measured fairness; soak-stable operation | Graphics M-GL4 (60 fps, no forcing) and M-GL5 (two VMs, two mdevs); CUDA battery + soak; per-guest execution isolation = rungs 4/5 | `[ahead]` | | **P4 — Breadth** | Video (NVENC/NVDEC), Windows/DirectX guests, live migration, non-KVM hypervisor transports | Per-case bring-up gates plus the matrix's evidence expectations | `[ahead]` | | **P5 — Scale and portability** | New GPU generations and driver families carried forward; published performance programme | A profile + measured delta per version, validated on hardware; A/B numbers published per the measurement contract | `[ahead]` | @@ -61,15 +61,17 @@ Ranked, in dependency order: stock GLX path are fully green (`glxinfo -B` rc 0, ~520 FPS `glxgears`), the X DDX/ScreenInit stability walls are closed (X green >10 minutes), the DDX 3D replay runs, the first non-black GPU-rendered frames and videos are - captured off-screen, captured GL sections execute on the engine, and the - direct-GL push bodies decode as real GR method streams above 10 GiB. The - named walls are **registration of the direct-GL payload user/UVM VAS** - (the `0x4001004` setup push and `0x4250000`/`0x4250110` draws still resolve - to zero/implausible PAs, so no draw section opens for `0xbeef0100` and - GZDoom spins after `V_Init`), the window/screen present path (glxgears' - window is black and a window draw wedges X), the X first-generation - screen-init lottery (even `modeNum` required), and then non-black window - frames. Full detail: + captured off-screen, captured GL sections execute on the engine, the + direct-GL submission is fully decoded (macro-driven; no method-grammar + draw header), and the client's draw-state push reaches the engine with the + golden MME overlay. The named walls are **MME macro completion** (the + 2799-word packed program cannot fit the <=2048-word block with the + 156-400-word draw window, so `live_gen` never promotes; the multi-part + keep-window mechanism is committed default-off with the A/B pending), the + window/screen present path (glxgears' window is black and a window draw + wedges X), the X first-generation start lottery (even `modeNum` required; + now the dominant throughput limiter), and then non-black window frames. + Full detail: [`Graphics-Execution.md`](Graphics-Execution.md) §6. 2. **Compute hardening (P1).** The staged-transfer class (failure modes proven, fixes in flight); the every-boot acceptance campaign; per-guest execution diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md index 3e7c54f..d556f4f 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-13, tree `master @ 436cbf9d`. Tags: `[live]` proven with the +Status: 2026-11-14, tree `master @ 339da842`. 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. @@ -26,9 +26,9 @@ named success state; `[planned]` designed, not built. | 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. 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 ([`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 X DDX idle-DMA/ScreenInit, USERD-latch lifetime, re-probe-thrash, Xorg kernel-mode-spin and flip-event walls were closed in the 11-12/11-13 wave (X green for >10 minutes in a validated window), leaving a per-boot first-generation X lottery (an X started immediately after boot passes DDX DMA init; 3/7 windows); the display-capability seam is parameterised ([`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 X DDX idle-DMA/ScreenInit, USERD-latch lifetime, re-probe-thrash, Xorg kernel-mode-spin and flip-event walls were closed (X green for >10 minutes in a validated window); what remains is the per-boot **first-generation X start lottery**, which by 11-13/11-14 was the dominant throughput limiter for the graphics A/B runs (only an X started immediately after boot passes DDX DMA init; long stretches of dead starts, one green first-start boot). 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 and the stock NVIDIA GLX path are fully green (`glxinfo -B` returns 0 with OpenGL 4.6.0 and direct rendering; `glxgears` renders ~520 FPS with the emulated GPU's NVIDIA renderer), and the **first non-black GPU-rendered output** is proven: the pbuffer frame path produced 500/500 non-black 640x480 frames per run and captured videos (45.4 s on 2026-11-11; a 50 s 640x480 h264 capture on 2026-11-12). GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context whenever the shared nvClip `modeNum` is even. **The frontier is delivery of the direct-GL client's own command stream:** the lookalike gate and the live-PA-bound fix (10 GiB raised to the registered guest-RAM top, 14 GiB) now let the client's 13+ GiB page directories walk and decode real GR method streams, and its GR ring resolves through its own VAS; but the GL setup push (59,556 bytes at VA `0x4001004`) and the draw pushes (`0x4250000`/`0x4250110`) still resolve to zero/implausible PAs because their user/UVM VAS is never registered, so no draw section opens for `0xbeef0100` and the window stays black. The engine-zero-write campaign showed the store wall is upstream of the draw (the replayed 221-word window is draw-free); the window/screen present path is unproven, and the X screen-init first-generation lottery remains ([`OpenGL.md`](OpenGL.md)) | +| OpenGL (3D graphics) | `[wip]` — the display/KMS stack registers, X and the stock NVIDIA GLX path are fully green (`glxinfo -B` returns 0 with OpenGL 4.6.0 and direct rendering; `glxgears` renders ~520 FPS with the emulated GPU's NVIDIA renderer), and the **first non-black GPU-rendered output** is proven: the pbuffer frame path produced 500/500 non-black 640x480 frames per run and captured videos (45.4 s on 2026-11-11; a 50 s 640x480 h264 capture on 2026-11-12). GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context whenever the shared nvClip `modeNum` is even. **The direct-GL submission is now fully decoded:** no client push carries a method-grammar draw header — the channel's 9 NV906F entries tile one contiguous buffer and its per-frame work is carried as rewritten data-block blobs plus small state pushes (324/476/728 B) that invoke MME macros (the QMD-carrier hypothesis was tested and refuted). A content-gated FB-shadow rescue and a LOW-band rescue recover the recycled pushes: the client's draw-state push now opens a C597 section, is captured and marked for the verbatim 3D lane (the first direct-GL stream3d marks), and reaches the engine (`GR LAUNCH submitted`/`OK`, golden MME overlay accepted). **The current wall is MME macro completion:** the beef lane's 2799-word packed program cannot complete inside its <=2048-word block together with the 156-400-word draw window, so the load-only carrier gate drops each beef window and `live_gen` never promotes (a multi-part keep-window mechanism is committed default-off and enabled in the campaign params; A/B pending). RT routing was tested and refuted as the store cause (RT0 bind verified 16x but still `wrote=0`), and the earlier `CODESRC` fault-park class is prevented (zero `FAULT_PDE`/`WEDGE-REARM` on the validated boot). The window stays black (`px0=0`, `wrote=0`); the window/screen present path is unproven, and the X start lottery is the throughput limiter ([`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]` | @@ -79,11 +79,12 @@ stack and the X server on the emulated vGPU (`glxinfo` reports OpenGL 4.6.0 with direct rendering, `glxgears` renders ~520 FPS); the first non-black GPU-rendered frames are proven off-screen (the pbuffer path produced a 500-frame 45.4 s video on 2026-11-11 and a 50 s capture on 2026-11-12), and -GZDoom reaches its screen-allocation stage with GL 4.6.0 on an even modeNum, -but windowed/screen pixels remain the frontier (the direct-GL payload VAs -still resolve to zero/implausible PAs because their user/UVM VAS is never -registered, and X screen-init keeps a first-generation lottery) — see -[`OpenGL.md`](OpenGL.md). The +GZDoom reaches its screen-allocation stage with GL 4.6.0 on an even modeNum. +The direct-GL submission is fully decoded (no classic draw header; the work is +macro-driven and the client's state push now reaches the engine), but +windowed/screen pixels remain the frontier (the MME multi-part program cannot +yet complete, the store still misses, and X start keeps a first-generation +lottery) — see [`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. diff --git a/wiki/System-Overview.md b/wiki/System-Overview.md index 33cf881..aeefb46 100644 --- a/wiki/System-Overview.md +++ b/wiki/System-Overview.md @@ -7,7 +7,7 @@ > and [`../docs/03-architecture/10-interaction-and-scheduling.md`](../docs/03-architecture/10-interaction-and-scheduling.md) > for the full picture); the docs tree wins on disagreement. -Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` proven with the +Status: 2026-11-14, tree `master @ 339da842`. Tags: `[live]` proven with the stock guest driver; `[gated]` implemented default-off; `[wip]` partial; `[wall]` current blocker; `[target]` designed end state. @@ -148,15 +148,19 @@ RPC from the guest to "firmware": execute on the engine, the 2D path is green, the direct-GL ring/USERD machinery is hardened, the first non-black GPU-rendered frames and captured videos (45.4 s and 50 s) are proven off-screen, and the guest Vulkan - pipeline runs end to end. The client's push bodies decode as real GR method - streams above 10 GiB through the VAS walk, but the direct-GL payload VAs - (setup push `0x4001004`, draws `0x4250000`/`0x4250110`) still resolve to - zero/implausible PAs because their user/UVM VAS is never registered (so - its draws never reach the engine); the window/screen present is unproven - (a window draw can wedge X and glxgears' window is black), and X - screen-init keeps a first-generation lottery, so the remaining gate is - that registration plus the window/screen present before the first - non-black window frame + pipeline runs end to end. The direct-GL submission is fully decoded: no + client push carries a method-grammar draw header (the work is macro-driven + — data-block blobs plus small state pushes invoking MME macros), the + recycled pushes are recovered, and the client's draw-state push opens, + captures and reaches the engine with the golden MME overlay. The wall is + MME macro completion: the 2799-word packed program cannot fit its + <=2048-word block with the draw window, so `live_gen` never promotes and + the draw never stores (RT routing was tested and refuted; the multi-part + keep-window A/B is pending). The window/screen present is unproven + (a window draw can wedge X and glxgears' window is black), and X start + keeps a first-generation lottery (the dominant throughput limiter), so the + remaining gate is the macro completion plus the window/screen present + before the first non-black window frame ([`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md)). ## 6. Where the detail lives |