diff options
Diffstat (limited to 'docs/09-reference/glossary-and-faq.md')
| -rw-r--r-- | docs/09-reference/glossary-and-faq.md | 19 |
1 files changed, 10 insertions, 9 deletions
diff --git a/docs/09-reference/glossary-and-faq.md b/docs/09-reference/glossary-and-faq.md index 2ec4faa..e0c68f6 100644 --- a/docs/09-reference/glossary-and-faq.md +++ b/docs/09-reference/glossary-and-faq.md @@ -5,7 +5,7 @@ | Term | Meaning | |---|---| | **AMAPlib** | NVIDIA's shared "address mapping" library: swizzling, bank/channel mapping, aperture rules. Studied for page-table and memory-layout semantics. | -| **Async copy engine (COPY14)** | A copy-engine instance found in the host oracle's engine list but missing from the emulated list — engine descriptor `0x793ceb0e`, instance 14, client type `0x38`, class pair `0xc9b5`. Its absence is the current CUDA context-creation blocker. | +| **Async copy engine (COPY14)** | A copy-engine instance found in the host oracle's engine list; engine descriptor `0x793ceb0e`, instance 14, client type `0x38`, class pair `0xc9b5`. Its earlier absence from the emulated list was a context-creation blocker; the emulated inventory now includes it (two GRCEs). | | **BAR0 / BAR1 / BAR3** | PCI BAR windows of the GPU: register interface (16 MB), VRAM aperture (256 MB), instance/PRAMIN window. | | **CE** | Copy Engine: DMA engine; also used for UVM's internal work. | | **Class list (classDB)** | The set of RM classes reported as supported (`GPU_GET_CLASSLIST`); engine queries are filtered against it, so the class list, engine list and caps controls must agree. | @@ -63,14 +63,15 @@ Yes — in the standalone configuration the distribution driver owns the physica GPU and Open-IOV is an independent module. Building NVIDIA's OpenRM modules from source is only needed for the native-vGPU-management workflows. -**Why is `nvidia-smi` working but CUDA not?** -CUDA startup reaches `cuInit` / `cuDeviceGet`, but context creation is blocked: -the emulated engine list lacks the async copy engine (`COPY14`), so -`cuCtxCreate` returns `rc=999` (`CUDA_ERROR_UNKNOWN`) and memory allocation -never runs. (The earlier `libcuda` segfault on this path was fixed by echoing -the request params back in the alloc reply.) Once context creation is green, -CUDA still needs *execution*: kernels must run on real hardware. See the -known-knowns document for the exact status and plan; start at +**Why is `nvidia-smi` working but my CUDA kernel not running?** +The driver-API path works: `cuInit`, device enumeration, `cuCtxCreate` and +the full smoke test (allocation, copies, free and destroy) complete, and a +guest kernel launch is forwarded to the physical engine queue. What has not +been observed yet is *execution*: the engine does not execute the forwarded +launch descriptor and no engine-authored release appears. That is the current +frontier, not a setup problem; the chosen execution backend is documented in +[`../03-architecture/08-physical-gpu-integration.md`](../03-architecture/08-physical-gpu-integration.md). +See the known-knowns document for the exact status and plan; start at [`../../userspace/cuda/READ-ME-FIRST.md`](../../userspace/cuda/READ-ME-FIRST.md). **How is this legal / license-clean?** |