diff options
Diffstat (limited to 'wiki/CUDA-Userspace-Driver.md')
| -rw-r--r-- | wiki/CUDA-Userspace-Driver.md | 24 |
1 files changed, 13 insertions, 11 deletions
diff --git a/wiki/CUDA-Userspace-Driver.md b/wiki/CUDA-Userspace-Driver.md index 6975a1d..c18a6ab 100644 --- a/wiki/CUDA-Userspace-Driver.md +++ b/wiki/CUDA-Userspace-Driver.md @@ -1,20 +1,23 @@ # CUDA Userspace Driver (`libcuda.so`) — Analysis Deep Dive -> **Status (2026-10-20, honest).** The analysis covers the whole library for +> **Status (2026-10-30, honest).** The analysis covers the whole library for > driver 570.144 and the tooling is version-agnostic. The *control plane* gets > the stock guest stack through `cuInit`, device enumeration, `cuCtxCreate` > and the full driver-API smoke test — allocation, copies, free and destroy > complete end to end (`ALL OK`; the 64-byte payload round-trips exactly). > The *data plane* decodes guest push buffers and executes the memory and > semaphore work it understands; CUDA kernel launches are forwarded to the -> physical execution path and now execute on the physical GPU — the +> physical execution path and execute on the physical GPU — the > engine-authored completions relay to the guest and its synchronisation > waits resolve. The vector-add (`VADD n=32768 bad=0`), matrix-multiply > (`MATMUL n=256 bad=0`) and transformer (`dh=256 seq=64 bad=0`, -> `FFN4 layers=4 bad=0`) clients verify green on fresh boots. The -> large-buffer staged-transfer class (multi-megabyte transfers between guest -> memory and device memory) is under repair, and reproducibility across fresh -> boots is being re-measured after the boot-poisoning fix. Canonical detail: +> `FFN4 layers=4 bad=0`) clients verify green on fresh boots, and a +> ring-block ownership defect that could stall the first client after a +> reboot was root-caused and fixed. The staged-transfer class (multi-megabyte +> transfers between guest memory and device memory) is under repair with its +> failure modes proven. Graphics (OpenGL/Vulkan) shares this driver's object +> machinery on a parallel frontier +> ([`Graphics-Execution.md`](Graphics-Execution.md)). Canonical detail: > [`01-architecture.md`](../userspace/cuda/docs/01-architecture.md) > through `08`; reading order > [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md); @@ -178,11 +181,10 @@ the data plane (`docs/08`). smoke test (allocation, copies, free and destroy). * **Current frontier:** guest CUDA kernel launches execute on the physical GPU with engine-authored completions relayed to the guest; the verified - clients are green on fresh boots. The leading edge is the large-buffer - staged-transfer class (some large multi-chunk clients still mis-verify), - re-measurement of reproducibility across fresh boots after the - boot-poisoning fix, and per-guest execution isolation. The chain, the - evidence and the live state are on + clients are green on fresh boots. The leading edge is the staged-transfer + class (some large multi-chunk clients still mis-verify, with the failure + modes proven), the every-boot acceptance campaign, and per-guest execution + isolation. The chain, the evidence and the live state are on [`Execution-Frontier.md`](Execution-Frontier.md). * **Data plane today:** the host module decodes guest push buffers as method streams and executes the memory and semaphore work it understands |