diff options
Diffstat (limited to 'wiki/Execution-Frontier.md')
| -rw-r--r-- | wiki/Execution-Frontier.md | 92 |
1 files changed, 62 insertions, 30 deletions
diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md index 2d9d80c..c8d42cc 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-10-30, tree `master @ b4930168`. Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories are labelled as such. @@ -72,21 +76,36 @@ 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. + 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. -No breadth beyond these is claimed: OpenGL/Vulkan, Windows guests, migration -and performance numbers remain planned. +### A parallel frontier: 3D graphics + +Graphics execution shares this page's submission and completion machinery but +runs a different engine workload. The story so far: the X server and GLX run +on the emulated vGPU; the emulation captures the X server's graphics-class +stream and the engine executes it — both as a verbatim 3D method-stream replay +and as a synthesized launch that retires real `sm_75` SASS — and the guest +Vulkan pipeline runs end to end (device → command buffer → fence → readback). +What is missing is **rendered pixels**: every frame is still black, and the +program-delivery/program-VA-mapping pair is the working frontier. 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 +144,41 @@ 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 engine executes graphics method +streams, but no rendered (non-black) frame has been produced yet; program +delivery and program-VA mapping 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** — materialise the driver's program + uploads and map the program VA so draws execute with real state; the lanes, + the walls and the milestone ladder are on + [`Graphics-Execution.md`](Graphics-Execution.md). ## 7. Theories, resolved @@ -157,8 +186,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 +213,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. |