# DirectX

> **Scope.** The Windows guest path — Direct3D and the rest of the DirectX
> family — as a **project target**: how the Windows NVIDIA stack relates to
> the interface Open-IOV already emulates for Linux, what a bring-up would
> require, and what has *not* happened yet (no Windows guest has been booted
> on the emulated vGPU). Linux graphics is covered on
> [`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) and
> [`Graphics-Execution.md`](Graphics-Execution.md). Canonical sources:
> [`../docs/03-architecture/02-guest-stack-and-cudasw.md`](../docs/03-architecture/02-guest-stack-and-cudasw.md)
> (guest stack) and
> [`../docs/06-portability/hardware-software-matrix.md`](../docs/06-portability/hardware-software-matrix.md)
> (support ladder). The docs tree wins on disagreement.

Status: 2026-10-30, tree `master @ b4930168`. Tags: `[target]` designed for,
bring-up not started; `[planned]` roadmap; no Windows-specific code exists in
the project today.

## 1. The Windows graphics stack

```text
Direct3D application (D3D12 / D3D11 / D3D9) or CUDA application
  -> DXGI (swap chains, adapters, presentation)
  -> user-mode display driver (UMD): nvd3dumx / nvwgf2umx   [D3D]
  -> kernel-mode driver (KMD): nvlddmkm.sys, under WDDM
  -> GPU
Windows kernel graphics subsystem (dxgkrnl)
  -> GPU scheduler, video-memory manager (VidMm), residency, TDR
```

Two structural differences from Linux matter for this project:

* **WDDM owns more of the pipeline.** The OS schedules command buffers
  submitted by the UMD, manages video-memory residency, and runs the GPU
  scheduler in the kernel; the driver's KMD programs hardware contexts and
  fences beneath that. (D3D12 exposes queues and fences with an explicit
  model that is closer to Vulkan than older APIs were.)
* **The device bring-up is different.** A Windows display adapter starts
  through the OS's display/PDO path (adapter enumeration, ROM/VBIOS views,
  VIDPN topology, power transitions), not the Linux DRM/modeset path. On
  Turing and later, however, the driver still talks to the **same GSP
  firmware resource manager** — the interface `vgsp.ko` emulates.

CUDA on Windows rides the same KMD with its own userspace driver, so the
device-facing requirements overlap almost entirely with the Linux CUDA work
already proven ([`Execution-Frontier.md`](Execution-Frontier.md)).

## 2. What this means for Open-IOV

The project's architecture does not change for Windows: **emulate the
firmware interface, pass the work through, patch nobody.** The Windows KMD
would be stock (signed, as shipped); the emulation must satisfy its
device-view and its GSP-RM usage. The measured bring-up items, from
[`../docs/06-portability/hardware-software-matrix.md`](../docs/06-portability/hardware-software-matrix.md):

* WDDM device start on the emulated device (PDO/display path, MSI-X and
  interrupt semantics).
* ROM/VBIOS provisioning in the device profile (Windows adapters expect one).
* Power-management transitions (Dx states) and reset behaviour.
* D3D/DXGI device creation, then compute (CUDA on Windows), then rendering
  through the same execution lanes as Linux.

## 3. Status

| Item | State |
|---|---|
| Windows guest boots on the emulated vGPU | `[planned]` — not started |
| KMD (`nvlddmkm.sys`) initialises on the emulated device | `[target]` |
| CUDA on Windows (driver-API smoke) | `[target]` |
| Direct3D device creation / rendering | `[target]` |
| Multi-VM Windows guests | `[target]` |

The support matrix lists **Windows x86_64 (WDDM driver, CUDA, 3D)** as
**Target**: the architecture is designed for it; the bring-up is ahead. The
proposed ladder mirrors the Linux milestones: KMD initialises → adapter
enumeration healthy → CUDA-on-Windows driver-API smoke → D3D device creation
→ first compute execution → first rendered pixels → multiple VMs.

## 4. What the project will not do

* No Windows-specific code inside the guest — no patched `nvlddmkm`, no
  shims in the guest kernel, no guest agent. Any Windows-only quirk belongs
  in the host module's device model.
* No reliance on the vendor vGPU host stack; the same mediator answers both
  guest OS families.
* The two-VM GPU demo videos published so far used **Linux** guests (and, for
  the `virgl` variant, a labelled non-vGPU path); neither is DirectX.

## 5. Related pages

* [`Graphics-Execution.md`](Graphics-Execution.md) — the execution lanes
  Direct3D would use.
* [`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) — the Linux API paths,
  further along.
* [`Hardware-Software-Matrix.md`](Hardware-Software-Matrix.md) — the support
  ladder, including the Windows target row.
* [`Guest-Stack-and-CUDASW.md`](Guest-Stack-and-CUDASW.md) — §7 covers
  the Windows kernel-mode driver and the no-guest-code rule.
* [`../docs/06-portability/hardware-software-matrix.md`](../docs/06-portability/hardware-software-matrix.md) —
  the canonical matrix and what each support level means.