Introduction
Microsoft is actively working on the Microsoft Compute Driver Model (MCDM), a new driver model that will be used instead of the Windows Display Driver Model (WDDM) to allow our silicon partners to provide drivers for hardware capable of compute only workloads. The MCDM is currently being defined and a release date has not been set. It is hoped that the MCDM will be released sometime in 2019.
Prior to the release of the MCDM, our silicon partners can begin work towards a MCDM driver by writing a compute only driver but using WDDM 2.3+. A compute only driver written using WDDM 2.3+ can be made to be work well with compute only workloads but will not be generally well behaved under all circumstances and thus is not viable for general public release. What follows is a general description of how to construct such a driver.
Please note, when MCDM is released the following guide will be updated to instead direct how to use MCDM instead of WDDM.
There is a good deal of documentation available that describes the WDDM. This documentation can be difficult to navigate and understand given how it was authored over time. This documentation is an attempt to help a developer navigate that documentation by providing a general overview of the driver and how it is built with pointers as needed to existing available documentation.
Driver Makeup
A WDDM driver is made up of at a minimum two separate binaries: a kernel mode driver binary and a user mode driver binary. The kernel mode binary is loaded when Plug-n-play (PnP) discovers a device node requiring the driver. The user mode driver, built as a dynamic link library (DLL), is loaded in a user mode process when the process attempts to enumerate the existence of the device.
The driver package consists at at minimum of: the INF file, the kernel mode binary and the user mode binary. The INF file describes what type of driver the package represents and where to find the driver binaries relative to the INF file.
You will see in some documentation that the kernel mode driver binary refered to as a miniport driver. This is because the driver loaded by PnP is actually a driver provided by Microsoft, the dxgkrnl.sys binary (aka grahics kernel driver). The graphics kernel driver is actually responsible for initiating the loading of the kernel mode binary provided by the hardware vendor, the miniport driver. When OS components, such as the power subsystem, interact with the graphics hardware it actually communicates directly with the graphics kernel driver which in turn call into the miniport driver as needed.
Kernel Mode Driver
As mentioned, the kernel mode driver binary is loaded by PnP. After loading the PnP into the OS kernel, the OS will attempt call the driver's DriverEntry routine. The OS expects the driver binary to export DriverEntry (and it is usually the only export for the kernel binary).
DriverEntry
The DriverEntry method is responsible for initializing the drivers state, getting it ready to be called by the OS, and then calling DxgInitialize with version information and a set of device driver interface (DDI) routines which the OS will call in order to interact with the driver. When calling DxgkInitialize, the driver provides a pointer to driver initialization data (DRIVER_INITIALIZATION_DATA) which contains DX Graphics Kernel Device Driver Interface (DXGKDDI_INTERFACE_VERSION) version that the driver was compiled with and the set of DDI routines. The set of DDI that is provided is dependent upon the DXGKDDI_INTERFACE_VERSION that is reported.
During the call to DxgkInitialize, the OS will call the driver via the DDI routines provided and thus a driver should be prepared to handle these calls. The DRIVER_INITIALIZATION_DATA provided will be copied by the OS and thus the driver DDI methods can not be changed after being provided to the OS.
DDI Required to be Implemented
The driver must provide a pointer to an appropriate method for all DDI entries in the DRIVER_INITIALIZATION_DATA it provides DxgkInitialize. At a minium, an empty DDI method must be provided that does nothing but return gracefully with an appropriate error code as needed. In order for the driver to work appropriately as a compute only driver, there is a minimum set of DDI methods that must actually be implemented and can not just be empty methods.
Here is the list of DDI methods that must be implemented for a WDDM 2.3 compute only driver: