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

Written by Michael Larabel in Microsoft on 20 May 2020 at 12:00 AM EDT. 39 Comments
MICROSOFT
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.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week