WikiBot: New page (2026-10-30 wiki refresh): DirectX

2026-10-30T17:05:03Z

New page (2026-10-30 wiki refresh): DirectX

New page

{{About message}}

= DirectX =

<blockquote>'''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|<code>OpenGL.md</code>]], [[Vulkan|<code>Vulkan.md</code>]] and [[Graphics Execution|<code>Graphics-Execution.md</code>]]. Canonical sources: [https://git.vgpu.io/open-iov.git/tree/docs/03-architecture/02-guest-stack-and-cudasw.md <code>../docs/03-architecture/02-guest-stack-and-cudasw.md</code>] (guest stack) and [https://git.vgpu.io/open-iov.git/tree/docs/06-portability/hardware-software-matrix.md <code>../docs/06-portability/hardware-software-matrix.md</code>] (support ladder). The docs tree wins on disagreement.</blockquote>

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

== 1. The Windows graphics stack ==

<pre>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</pre>

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 <code>vgsp.ko</code> 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 ([[The Execution Frontier|<code>Execution-Frontier.md</code>]]).

== 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 [https://git.vgpu.io/open-iov.git/tree/docs/06-portability/hardware-software-matrix.md <code>../docs/06-portability/hardware-software-matrix.md</code>]:

* 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 ==

{| class="wikitable"
|-
! Item
! State
|-
| Windows guest boots on the emulated vGPU
| <code>[planned]</code> — not started
|-
| KMD (<code>nvlddmkm.sys</code>) initialises on the emulated device
| <code>[target]</code>
|-
| CUDA on Windows (driver-API smoke)
| <code>[target]</code>
|-
| Direct3D device creation / rendering
| <code>[target]</code>
|-
| Multi-VM Windows guests
| <code>[target]</code>
|}

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 <code>nvlddmkm</code>, 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 <code>virgl</code> variant, a labelled non-vGPU path); neither is DirectX.

== 5. Related pages ==

* [[Graphics Execution|<code>Graphics-Execution.md</code>]] — the execution lanes Direct3D would use.
* [[OpenGL|<code>OpenGL.md</code>]], [[Vulkan|<code>Vulkan.md</code>]] — the Linux API paths, further along.
* [[Hardware and Software Matrix|<code>Hardware-Software-Matrix.md</code>]] — the support ladder, including the Windows target row.
* [[The Guest Stack and CUDASW|<code>Guest-Stack-and-CUDASW.md</code>]] — §7 covers the Windows kernel-mode driver and the no-guest-code rule.
* [https://git.vgpu.io/open-iov.git/tree/docs/06-portability/hardware-software-matrix.md <code>../docs/06-portability/hardware-software-matrix.md</code>] — the canonical matrix and what each support level means.

DirectX - Revision history

WikiBot: New page (2026-10-30 wiki refresh): DirectX