diff options
Diffstat (limited to 'wiki/FAQ.md')
| -rw-r--r-- | wiki/FAQ.md | 44 |
1 files changed, 31 insertions, 13 deletions
diff --git a/wiki/FAQ.md b/wiki/FAQ.md index 9472740..d3e42db 100644 --- a/wiki/FAQ.md +++ b/wiki/FAQ.md @@ -5,7 +5,7 @@ > [`../docs/09-reference/glossary-and-faq.md`](../docs/09-reference/glossary-and-faq.md); > the docs tree wins on disagreement. -Status: 2026-10-12, tree `master @ 2f066727`. +Status: 2026-11-11, tree `master @ 4acac093`. ## Project and positioning @@ -27,26 +27,44 @@ not for the QEMU/emulated path ([`Install-and-First-Run.md`](Install-and-First-Run.md) §2). **Why is `nvidia-smi` working but my CUDA kernel not running?** -Because execution is the frontier, not the setup. Today, a stock guest driver -probes, `nvidia-smi` works, device enumeration works, and the full CUDA -**driver-API** path (context creation, allocation, copies, free, destroy) -completes; a guest **kernel launch** is forwarded to the physical engine queue -but the engine does not yet execute the forwarded launch descriptor -(`[wall]`). This is the project's known status, not a misconfiguration — see +It probably is running: guest CUDA kernels execute on the physical GPU and +verify — the vector-add, matrix-multiply and transformer clients are green on +fresh boots. If a specific workload fails, the known classes are: multi-megabyte +staged transfers between guest and device memory (under repair, failure modes +proven), and simultaneous CUDA guests (per-guest execution isolation is in +progress). This is the project's known status, not a misconfiguration — see [`Project-Status.md`](Project-Status.md) and [`Execution-Frontier.md`](Execution-Frontier.md). +**Can I run OpenGL or Vulkan applications in the guest?** +Partially, and it is an active frontier. The display/KMS stack and the X +server run on the emulated vGPU with the stock driver: nvidia-modeset/NvKms +registers (`/dev/dri`), `glxinfo` reports OpenGL 4.6.0 with direct rendering, +the 2D path is green and the DDX 3D replay executes. The **first non-black +GPU-rendered output** is proven: a pbuffer probe returns `pixel=ff0000ff`, the +off-screen path produced 500/500 non-black animated frames, and a 45.4 s video +was captured. The direct-GL GR channel now submits and its releases advance; +GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context. Window and +screen pixels are still the wall: glxgears' window is black, the direct-GL CE +channel does not yet resolve (GZDoom wedges ~90 s after `V_Init`), X window +creation wedges on some boots, and the DDX's 4 GB sysmem allocation forces a +12 GB guest. The guest Vulkan pipeline runs end to end (device → command +buffer → fence → readback) but frames are black. See +[`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) and +[`Graphics-Execution.md`](Graphics-Execution.md). + **How fast is it?** -No published numbers yet. Copy-engine-class forwarding and its completion and -fault relay are implemented (default off) and GR execution is the open -frontier; even the initialization path has not yet been measured under the -project's methodology. Any performance claim will ship together with its -methodology and measurements. +No published numbers yet. Kernel launches execute on the physical engine; +what remains unmeasured is the project's own methodology — nothing ships as a +performance claim without its measurements. The first scheduled measurement +is the graphics target (60 fps sustained in one VM, no forcing). ## Compatibility **Will it support Windows guests?** -Yes, it is a target: same architecture, measured bring-up. +Yes, it is a target: same architecture, measured bring-up. No Windows guest +has been booted on the emulated vGPU yet; the Windows/DirectX path (WDDM, +`nvlddmkm`, Direct3D) is described on [`DirectX.md`](DirectX.md). [`Hardware-Software-Matrix.md`](Hardware-Software-Matrix.md) lists the support ladder. |