diff options
Diffstat (limited to 'wiki/Execution-Frontier.md')
| -rw-r--r-- | wiki/Execution-Frontier.md | 109 |
1 files changed, 78 insertions, 31 deletions
diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md index 2d9d80c..fc076f1 100644 --- a/wiki/Execution-Frontier.md +++ b/wiki/Execution-Frontier.md @@ -4,13 +4,17 @@ > must fire for a stock guest CUDA kernel to run on the physical GPU, what has > been proven about it, how we know, and where the leading edge is now. The > chain fires end to end: verified guest CUDA clients execute on the physical -> GPU and wake up correctly; the leading edge is now breadth and hardening. It +> GPU and wake up correctly; the leading edge is now breadth and hardening. A +> **parallel graphics frontier** (OpenGL/Vulkan execution) shares the same +> submission machinery at a different execution layer — +> [`Graphics-Execution.md`](Graphics-Execution.md), +> [`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md). It > is evidence-led: every statement carries a live observation, a > decompilation finding, or a clearly labelled theory. Condensed from > [`../docs/04-implementation/03-execution-frontier.md`](../docs/04-implementation/03-execution-frontier.md); > the docs tree wins on disagreement. -Status: 2026-10-20, tree `master @ 16291c72`. +Status: 2026-11-11, tree `master @ 4acac093`. Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories are labelled as such. @@ -72,21 +76,45 @@ synchronisation waits resolve. The leading edge has moved from the launch chain itself — it fires — to breadth and hardening around it: -* **The large-buffer staged-transfer class.** Multi-megabyte staged transfers - between guest memory and device memory are under repair: some large - multi-chunk clients still mis-verify. -* **Reproducibility across boots.** A boot-poisoning defect was root-caused - and fixed: under the driver's status-queue mode the emulation read the wrong - queue cursor, so under load the reply ring could desynchronise and the first - CUDA client would fail (the user-visible `STATUS FAIL`-then-freeze report). - Re-measurement across fresh boots is in progress. +* **The staged-transfer class.** Multi-megabyte transfers between guest memory + and device memory are under repair: some large multi-chunk clients still + mis-verify, with the failure modes proven (a release applied before the op + it owes, a ledger-vs-writer page divergence, and a readback racing a + writeback). +* **Reproducibility across boots.** Two defects landed and were fixed: the + boot-poisoning defect (under the driver's status-queue mode the emulation + read the wrong queue cursor, so under load the reply ring could + desynchronise and the first CUDA client would fail) and a ring-block + ownership defect that could stall the first client after a reboot. Green + clients reproduce across fresh boots; a formal every-boot campaign remains. * **Per-guest execution isolation.** Multiple mediated devices with different - emulated VRAM sizes and multiple guests already coexist at the device level; - per-guest execution isolation for multiple simultaneous CUDA guests is in - progress. - -No breadth beyond these is claimed: OpenGL/Vulkan, Windows guests, migration -and performance numbers remain planned. + emulated VRAM sizes and multiple guests already coexist at the device level + (two guests demonstrated); per-guest execution isolation for multiple + simultaneous CUDA guests is in progress. + +### A parallel frontier: 3D graphics + +Graphics execution shares this page's submission and completion machinery but +runs a different engine workload. The display and GL stacks now run end to +end in the guest: the emulated display engine serves the modeset push buffers, +nvidia-modeset/NvKms registers (`/dev/dri`), X settles, `glxinfo` reports +OpenGL 4.6.0 with direct rendering, and the X DDX waits are fixed +(class-aware display arm, `0x8000 -> 0` notification completion, decoded GL +release applied); the direct GL client's GR and CE channels submit and retire, +and the X DDX kick channel is decoded. The **first non-black GPU-rendered +output** landed: a pbuffer probe returns `pixel=ff0000ff`, the off-screen +path produced 500/500 animated 640x480 frames, and a 45.4 s video was +captured. The direct-GL **GR ring `0xbeef0100` now resolves** and its releases +advance; GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context +whenever the shared nvClip `modeNum` is even. What is missing is **window/ +screen pixels through the NVIDIA path**: glxgears' window is black, the +direct-GL **CE ring `0xbeef0101` never resolves** (the guest wedges ~90 s +after `V_Init`), and X window creation wedges 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). + +No breadth beyond these is claimed: Windows guests, migration and performance +numbers remain planned. ## 3. How we know (observables and their limits) @@ -125,31 +153,47 @@ boots. ## 5. The clear issues (ranked) -**Issue A — the large-buffer staged-transfer class.** Multi-megabyte staged -transfers between guest memory and device memory are under repair: some large -multi-chunk clients still mis-verify. +**Issue A — the staged-transfer class.** Multi-megabyte transfers between +guest memory and device memory are under repair: some large multi-chunk +clients still mis-verify, with the failure modes proven and named. -**Issue B — reproducibility across boots (re-measurement).** The -boot-poisoning defect (wrong status-queue consumption cursor under the -driver's status-queue mode; the reply ring could desynchronise under load, the -first client would fail) was root-caused and fixed. Re-measurement across -fresh boots is in progress; no "every boot" claim is made until it completes. +**Issue B — every-boot reproducibility (acceptance campaign).** The +boot-poisoning defect and the post-reboot ring-block ownership defect were +root-caused and fixed, and green clients reproduce on fresh boots; the formal +every-boot acceptance campaign is the remaining work. **Issue C — per-guest execution isolation.** Multiple mediated devices with -different emulated VRAM sizes and multiple guests coexist at the device level; -per-guest execution isolation for simultaneous CUDA guests is in progress. +different emulated VRAM sizes and multiple guests coexist at the device level +(two guests demonstrated); per-guest execution isolation for simultaneous +CUDA guests is in progress. + +**Issue D — the graphics pixel frontier.** The display/KMS stack and the GL +client now run end to end (NvKms registers, X settles, GL 4.6, the DDX 3D +replay executes, the first non-black GPU-rendered frames and a 45.4 s video +are captured off-screen, and the direct-GL GR ring resolves with advancing +releases); but the direct-GL CE ring `0xbeef0101` does not resolve, a +window draw wedges X and glxgears' window is black, and no non-black window/ +screen frame has been produced. The CE ring, the window/screen present and X +stability are the named blockers +([`Graphics-Execution.md`](Graphics-Execution.md)). ## 6. Lines of investigation (live) -1. **Repair the large-buffer staged-transfer class** — the three green clients +1. **Repair the staged-transfer class** — the green clients stay the regression battery and must remain green throughout. -2. **Complete the fresh-boot re-measurement** — demonstrate the fixed boot - path across fresh boots before claiming boot-to-boot reproducibility. +2. **Complete the every-boot acceptance campaign** — demonstrate the fixed boot + path across a defined run of fresh boots before claiming boot-to-boot + reproducibility. 3. **Per-guest execution isolation** — build from the device-level coexistence to isolation for simultaneous CUDA guests. 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** — resolve the direct-GL CE ring + `0xbeef0101`, make the window/screen present land, and stabilise X across + boots 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 @@ -157,8 +201,9 @@ The descriptor-gate theories (T1–T4) are resolved and are not kept as open: the inline-descriptor install, the engine's QMD read, the grid dispatch, the engine-authored release and the guest wake-up are all directly observed, so the launch chain they questioned is proven end to end. The remaining work is -engineering (large-buffer transfers, boot-to-boot reproducibility, per-guest -isolation), each with an acceptance signal named before the work. +engineering (staged transfers, an every-boot acceptance campaign, per-guest +isolation, the graphics pixel frontier), each with an acceptance signal named +before the work. ## 8. Claim discipline @@ -183,6 +228,8 @@ isolation), each with an acceptance signal named before the work. client path. * [`Physical-GPU-Backend.md`](Physical-GPU-Backend.md) — the backend the work is forwarded to. +* [`Graphics-Execution.md`](Graphics-Execution.md) — the parallel graphics + frontier (OpenGL/Vulkan), sharing this machinery. * [`Execution-Plane.md`](Execution-Plane.md) — the execution layer's design. * [`Introduction-to-GMMU.md`](Introduction-to-GMMU.md) — page tables, QMDs and the engines. |