The Answer’s 42

So yesterday, I got excited at the notion of DirectX 12 on Linux and well… now that there’s been a bit of time and discussion of this in kernel maintainer discussion threads, it’s not quite what I thought.

The fact that the DX12 library is going to be closed source would be a real problem as it doesn’t seem it would interact with DRM correctly, and so would be a real pain if this was shipped with any form of Linux. There is of course the precedent of nVidia shipping their binary blob drivers and it getting packaged together with Ubuntu and POP!_OS, but that’s a graphics card driver, and ultimately it implements Vulkan and OpenGL, two open standards.

Microsoft shipping a closed source API with Linux as standard seems a bit more of a problem. I doubt whether many distros would include it and a proprietary blob making its way into the kernel itself that ships would never, ever go down, as indicated in the thread I linked to above by Dave Airlie, one of the maintainers:

This is a driver that connects a binary blob interface in the Windows kernel drivers to a binary blob that you run inside a Linux guest.

It’s a binary transport between two binary pieces. Personally this holds little of interest to me, I can see why it might be nice to have this upstream, but I don’t forsee any other Linux distributor ever enabling it or having to ship it, it’s purely a WSL2 pipe. I’m not saying I’d be happy to see this in the tree, since I don’t see the value of maintaining it upstream, but it probably should just exists in a drivers/hyperv type area.

Dave Airlie

Apparently at this stage, not by the developers of the Linux DX12 themselves:

There is a single usecase for this: WSL2 developer who wants to run machine learning on his GPU. The developer is working on his laptop, which is running Windows and that laptop has a single GPU that Windows is using.

Since the GPU is being used by Windows, we can’t assign it directly to the Linux guest, but instead we can use GPU Partitioning to give the guest access to the GPU. This means that the guest needs to be able to “speak” DX12, which is why we pulled DX12 into Linux.

Sasha Levin

So my excitement at the arrival of DX12 in Linux was sort-of unfounded. It’s a module for the WSL2 Linux kernel, which is Linux, Jim, but not as we know it. Windows does seem to be transmogrifying itself into a Linux hybrid though, as a native command line package manager called Winget has been announced (although Chocolatey has been doing this for a while) and also Microsoft is working on its own implementation of Wayland – a world where Microsoft effectively is turning into a distro maintainer is still an odd one indeed.

Nevertheless, the excitement wasn’t entirely unwarranted. The idea of adding presentation to DX12 and perhaps integrating more with non-WSL Linux has apparently been discussed:

We have consider the possibility of bringing DX to Linux with no Windows cord attached. I’m not ready to discuss this at this time 😊… but in the hypothetical that we were do this, DX would be running on top of DRI/DRM on native Linux. We likely would be contributing some changes to DRM to address area of divergence and get better mapping for our user mode driver, but we wouldn’t try to shoehorn /dev/dxg into the picture. In that hypothetical world, we would essentially have DX target DRM on native Linux and DX continue to target DXG in WSL to share the GPU with the host. I think this further reinforce the point you guys were making that the right place for our current dxgkrnl driver to live in would be /drivers/hyperv/dxgkrnl. In insight, I totally agree 😊.

Steve Pronovost

And so potentially, one day we could see DirectX 12 arrive on non-Windows Linux distros, interacting properly with DRM and then making it so that you could write code targeting DX12 on Linux… which would be strange. I can see the point of easing applications running on WINE, as suddenly Windows apps are able to speak the language of Linux and will have virtually no problem running, but on the other hand Vulkan is already a low level API that targets Linux so do we need another?

We live in very strange times. It’ll be interesting to see where Microsoft go next with this. Any hostility I had towards Microsoft has long evaporated, but the idea of Microsoft as one of the most interesting companies in open source software is something I thought I’d only ever see when there were snowstorms in hell…