From 1fdbf4ea8c17dab2b8fca6b5e58c2a6d3bc7596d Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Tue, 29 Sep 2026 15:29:00 -0400 Subject: docs: record physical-GPU integration mechanism and refresh project status - add docs/03-architecture/08-physical-gpu-integration.md: interfaces that exist, mechanism options A-E, chosen path (module-owned GPU driven through its real GSP firmware), sharing policy, decision record - update 06-host-module-and-hybrid-model, 02-practical-challenges, system overview, known-knowns, docs/README reading order and CUDA-side docs to match - correct stale engine-topology/COPY14 blocker claims across the tree - add STATE-CURRENT.md as the dated public status snapshot --- docs/06-portability/hardware-software-matrix.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'docs/06-portability') diff --git a/docs/06-portability/hardware-software-matrix.md b/docs/06-portability/hardware-software-matrix.md index 49c4bbe..c839578 100644 --- a/docs/06-portability/hardware-software-matrix.md +++ b/docs/06-portability/hardware-software-matrix.md @@ -131,9 +131,9 @@ the profile files, not the profile schema. ### 6.2 Engine-list portability The engine inventory, and how it is filtered by the class list (classDB), are -per-architecture and per-driver data. Today's gap is concrete: the emulated -list lacks the async copy engine (`COPY14`), which blocks context creation -(`cuCtxCreate` returns `rc=999`). Engine inventory belongs in the hardware +per-architecture and per-driver data. An earlier gap was concrete — a missing +async copy engine (`COPY14`) blocked context creation until the inventory was +completed — and it showed why the inventory belongs in the hardware profile, validated against the host oracle per combination. For the re-analysis workflow see [`../../userspace/cuda/docs/07-version-upgrade-playbook.md`](../../userspace/cuda/docs/07-version-upgrade-playbook.md); -- cgit v1.2.3