diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-06 15:18:39 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-06 15:18:39 -0400 |
| commit | 929646875d80408a21c642ca88ef70efbc0d736a (patch) | |
| tree | deb2946cc4407e4edcc6e3b56f37420e321acf40 /docs/03-architecture/03-gsp-and-gsp-rm.md | |
| parent | 039daee13c5bac50919eff1ca26977ac49e37b06 (diff) | |
| download | open-iov-929646875d80408a21c642ca88ef70efbc0d736a.tar.gz open-iov-929646875d80408a21c642ca88ef70efbc0d736a.zip | |
docs: add the GR compute-launch frontier page and align execution status across the tree
New page docs/04-implementation/03-execution-frontier.md describes the chain
that must fire for a guest CUDA launch (guest push -> GPFIFO/front-end ->
inline launch-descriptor install -> engine read/dispatch -> completion),
where the leading edge is (the descriptor install path), how we know
(front-end vs engine-authored observables and their limits), what is
exonerated (context validity at dispatch, destination window mapping,
fetch alignment, shared-buffer rule, parenting), the ranked issues (verbatim
prelude targets, missing descriptor-virtualization control, sentinel
hygiene), live investigation lines and labelled theories.
Align every page that still said GR execution is blocked on engine-context
validity to the current frontier, and add the new page to the README reading
order (row 15, later rows renumbered). Docs only; no code.
Diffstat (limited to 'docs/03-architecture/03-gsp-and-gsp-rm.md')
| -rw-r--r-- | docs/03-architecture/03-gsp-and-gsp-rm.md | 8 |
1 files changed, 5 insertions, 3 deletions
diff --git a/docs/03-architecture/03-gsp-and-gsp-rm.md b/docs/03-architecture/03-gsp-and-gsp-rm.md index 10e6a73..56e77be 100644 --- a/docs/03-architecture/03-gsp-and-gsp-rm.md +++ b/docs/03-architecture/03-gsp-and-gsp-rm.md @@ -232,9 +232,11 @@ The engine-inventory row was the CUDA blocker at the time of writing: `libcuda` filters the engine list it receives against the class list and expects the async copy engine to be present, because the secondary (async) engine record is otherwise zeroed. That inventory is now complete and context -creation passes; the current frontier is engine execution, where CE-class -copies are forwarded to the physical copy engine (default off) and GR kernel -execution is blocked on GR engine-context validity. See +creation passes; the current frontier is engine execution: CE-class copies are +forwarded to the physical copy engine (default off), and for GR a forwarded +guest launch reaches the front-end but the inline launch-descriptor install has +not been observed (context validity at dispatch is ruled out; see +[`../04-implementation/03-execution-frontier.md`](../04-implementation/03-execution-frontier.md)). See [`../../userspace/cuda/docs/05-570.144-decompilation.md`](../../userspace/cuda/docs/05-570.144-decompilation.md) section 3.7 for the offsets and the consumed fields, and [`../../userspace/cuda/docs/03-driver-and-gpu-interface.md`](../../userspace/cuda/docs/03-driver-and-gpu-interface.md) |