Mainlining The Microsoft DirectX Kernel Driver For Linux Will Be An Uphill Battle

On Tuesday was the big announcement of Microsoft bringing Direct3D 12 to Linux/WSL2 in the context of allowing GUI applications and GPU compute within Windows Subsystem for Linux. This also means OpenCL/OpenGL/Vulkan support by ultimately converting it into D3D12 consumption by the host Windows system. While Microsoft was quick to post patches for their "dxgkrnl" kernel driver for this Direct3D implementation, it's already facing resistance and will be an uphill battle for it to be mainlined.

The DXGKRNL kernel driver for Linux sits between Microsoft's to-be-published proprietary Direct3D 12 libraries that sit in Linux user-space and the host system that will receive the instructions. DXGKRNL communicates with the host system via Microsoft Hyper-V.

With Microsoft keeping their Direct3D 12 Linux libraries closed-source, that immediately created some friction to no surprise while they attempt to upstream their open-source Linux kernel driver. From the Direct Rendering Manager (DRM) perspective, they do not normally allow drivers/features into the kernel that are contingent exclusively upon a proprietary client in user-space, as is the case here. So if they are trying to play nicely with upstream DRM, that immediately causes problems with the Direct3D 12 user-space libraries not going open-source.

Intel open-source developer Daniel Vetter who helps oversee the DRM subsystem immediately pointed out a number of problems, including the closed-source user-space. Among the issues raised by Vetter is that the DirectX kernel driver is "reinventing the world" in changing around device enumeration and a lot of other interfaces/features already supported in a common manner by upstream DRM drivers. There are also questions raised about how well this integrates with other common Linux features like DMA-BUF.

DRM maintainer David Airlie was also quick to characterize this as a driver that connects a binary blob interface in Windows to a binary blob in Linux guests. He personally sees little value in having this driver upstreamed and raised concerns over how this driver will ultimately handle its planned presentation bits for displaying of Linux GUI applications within WSL2. He also raised the possibility of this landing in the Linux kernel as part of the Microsoft Hyper-V drivers rather than in the DRM driver area.

Airlie also followed up that he isn't even fond of the idea of reviewing this open-source DXGKRNL code as since it's implementing proprietary Microsoft interfaces could potentially legally taint him in developing new graphics interfaces.

So we'll see where this goes but don't expect the DXGKRNL DirectX kernel driver to be mainlined in the immediate future.

Those wanting to follow the discussions can do so via this kernel mailing list thread.