DirectX

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, Vulkan.md and Graphics-Execution.md. Canonical sources: ../docs/03-architecture/02-guest-stack-and-cudasw.md (guest stack) and ../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

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).

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:

• 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 — the execution lanes Direct3D would use.
• OpenGL.md, Vulkan.md — the Linux API paths, further along.
• Hardware-Software-Matrix.md — the support ladder, including the Windows target row.
• 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 — the canonical matrix and what each support level means.