summaryrefslogtreecommitdiffstats
path: root/wiki
diff options
context:
space:
mode:
Diffstat (limited to 'wiki')
-rw-r--r--wiki/.publish-manifest.json110
-rw-r--r--wiki/Execution-Frontier.md57
-rw-r--r--wiki/Execution-Plane.md23
-rw-r--r--wiki/FAQ.md20
-rw-r--r--wiki/Graphics-Execution.md122
-rw-r--r--wiki/Host-Module.md13
-rw-r--r--wiki/OpenGL.md38
-rw-r--r--wiki/Physical-GPU-Backend.md13
-rw-r--r--wiki/Project-Goals.md6
-rw-r--r--wiki/Project-Plan.md26
-rw-r--r--wiki/Project-Status.md17
-rw-r--r--wiki/System-Overview.md24
12 files changed, 270 insertions, 199 deletions
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
generated by cgit v1.2.3 (git 2.39.1) at 2026-11-14 23:49:44 +0000