diff options
Diffstat (limited to 'docs/03-architecture/03-gsp-and-gsp-rm.md')
| -rw-r--r-- | docs/03-architecture/03-gsp-and-gsp-rm.md | 11 |
1 files changed, 6 insertions, 5 deletions
diff --git a/docs/03-architecture/03-gsp-and-gsp-rm.md b/docs/03-architecture/03-gsp-and-gsp-rm.md index aca908f..8809bb7 100644 --- a/docs/03-architecture/03-gsp-and-gsp-rm.md +++ b/docs/03-architecture/03-gsp-and-gsp-rm.md @@ -186,17 +186,18 @@ is not lost. | GSP boot state machine | ✅ | stages complete; the driver's poll loop is satisfied | | Message queue transport | ✅ | including the non-contiguous page table for the queue buffer | | RPC request/reply | ✅ | all functions the driver uses during init are answered; unknown functions get a success reply with no payload | -| Static info tables | 🟡 | device/FB/BUS/INTR/GMMU tables carry plausible TU104 values; the engine inventory is still incomplete (the async copy engine, COPY14, is missing) | +| Static info tables | 🟡 | device/FB/BUS/INTR/GMMU tables carry plausible TU104 values; the engine inventory is now complete (the async copy engine is included) and agrees with the class list | | Controls during init | 🟡 | ~160 distinct control IDs observed per CUDA run; 23 are special-cased with real values, the rest fall through to a success reply with zeroed parameters - consumed fields of those are still being corrected | | Object creation | 🟡 | handles/parameters are echoed consistently (the request parameters must be echoed back - zeroing them corrupts the caller), but there is no server-side object model: allocation is acknowledged, not tracked | | Page tables for server-owned ranges | 🟡 | contract received and recorded; leaf population is the forwarding work | | Event/notification delivery | 🟡 | MSI-X works; richer event semantics as forwarding lands | | Firmware *behaviour* (routing, scheduling, real execution) | 🔴 | the forwarding work; see the implementation docs | -The current CUDA blocker is the engine-inventory row: `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. See +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; the +context-creation wait is later, in the completion path. 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) |