WSL Microsoft ported DirectX 12 to its own Linux

WSL Microsoft ported DirectX 12

DirectX Linux | DirectX Developer Blog - Microsoft Developer

Directx 12 now runs without graphics in Linux, but only for the WSL.
For GPU support in its Windows subsystem for Linux (WSL), Microsoft has ported its Directx 12 graphics interface to Linux with a lot of effort and also with the help of the graphics card manufacturers. The manufacturer announces this at its virtual in-house trade fair Build.

Since the WSL in its current version 2 relies on virtualization via Hyper-V, Microsoft cannot provide direct access to the hardware. Therefore, a Linux kernel module was created, which simply forwards the graphics infrastructure used under Windows for Directx 12 to the WSL. Specifically, Microsoft has provided the dxgkrnl kernel mode driver with a Linux counterpart of the same name.

WSL Linux with Windows technology

This replica and the abstraction make it possible that Microsoft simply had to recompile its libraries for its own graphics interface in order to port them to Linux, as the announcement states. This applies to the D3D12 API, which is now available under Linux as libd3d12.so, as well as the new Dxcore (libdxcore.so).

Both mentioned libraries are still proprietary software and are automatically inserted into the environment by the loader of the WSL at startup. In addition, Microsoft has also ported its machine learning library Directml to this new stack and the graphics card manufacturers have adapted their userspace drivers, which now also run in Linux with Windows technology.

The same applies to Cuda from Nvidia, which can now also run on the basis of Directx12 in Linux. All of this work and ports have been used to support machine learning tasks or similar compute applications on the GPU.

Opengl over Directx12

Currently, Microsoft does not provide any specific information on the support of Vulkan. But the interfaces Opengl and Opencl, which are frequently used under Linux, are currently also being ported by Collabora to the new stack. This means that even those Linux applications that use this free interface should be able to easily access the graphics acceleration in the new WSL stack.

For the port, the Linux team relies on the free 3D graphics library Mesa. The goal here is to make the Directx-12 technique now ported to Linux available as a backend for Mesa, so that the free technique functions as a kind of translation layer. This is not unusual, there are similar approaches with the Vulkan API as backend. The code for the work on Mesa is already available as open source.

However, whether and to what extent the code created by Microsoft and its partners will end up in the main branches of the canonical Linux projects is difficult to estimate. This is exemplified by the discussion of the kernel community.

Inclusion in the Linux kernel with hurdles

As has become a good thing for Microsoft, the company is also trying to work actively and closely with the Linux community for this work. The Linux kernel driver created by Microsoft is therefore not only available as open source. The responsible team has also proposed the code for it on the Linux kernel mailing list for inclusion in the main branch of Linux and wants to participate actively in it.

The Linux developer Sasha Levin, who is employed by Microsoft, explains in detail the described structure in the e-mail as well as further details about the Linux driver itself. There, among other things, it is again explicitly shown that the structure does not yet contain any display functionality. Levin also writes, "This GPU stack is effectively next to the native Linux graphics stack."

The latter in particular is likely to make it much more difficult to integrate into the graphics subsystem of the kernel. After all, Microsoft has only rebuilt its own Windows interfaces for Linux for the Directx-12 port, instead of reusing the existing kernel interfaces and technology. Above all, this reuse and the associated cooperation with each other are a strength of the Linux community, which pushes them again and again.

It is therefore at least currently not foreseeable that the code in its current form will be inserted into the graphics subsystem. This is also written by Dave Airlie, who is responsible for it. Airlie assumes that the technology would probably never be used outside of the WSL by Microsoft and that classical Linux distributors would have accordingly little interest in it. The maintenance of the driver does not make sense for Airlie at the moment.

Discussion repeats itself

Similarly, Daniel Vetter, the main contributor to the Intel graphics driver under Linux, argues. He writes that there are some fundamental problems with the code. The most important thing is that the userspace part is completely proprietary. However, free userspace drivers are required for inclusion in the graphics subsystem of the kernel. Vetter also criticizes that Microsoft has simply not used some existing Linux technology, but has created completely new ones. Vetter also lacks other integrations with existing technology, such as memory management.

Despite their technical criticism, both Vetter and Airlie see the possibility that the Microsoft code will be treated similarly to other accelerator cards and thus end up in another subsystem for which they are not responsible. The criticism now presented by both of them had already presented them in a similar way a little over a year ago, when the Linux community discussed the creation of a subsystem for accelerator cards.

However, if Microsoft actually wants to extend the newly created technology by a real graphic representation, the discussion could start from the beginning, the graphics developers fear. Accordingly, the code should already be adapted if the implementation for a graphic representation on the part of Microsoft is planned.

Following the discussion it is to be assumed that the code in its present form at least will not end up in the graphics subsystem of Linux. However, admission as an accelerator driver seems quite obvious in the medium term. This is also supported by the fact that the developer Greg Kroah-Hartman has already dealt with the code. Kroah-Hartman was one of the proponents of creating the accelerator subsystem.