Thread by @grnr_s

So based on Microsofts "port of DirectX12 to Linux" announced at #MSBuild here is some (maybe far fetched, but hopefully not) thought/idea how this will turn out in the long run wrt drivers and will show how Open Source actually means community that benefits everyone involved.

So let's start with what we already have and what we already know:
The new Windows Subsystem for Linux (WSL 2) uses virtualization based on Hyper-V with a Linux kernel that Microsoft maintains themselves. (Yes, Microsoft ships Linux within Windows).

One of the most asked for requests by WSL users was GPU support.
Because WSL 2 basically runs as a VM the only way to do this, was to paravirt a GPU device.
On top of that they apparently wanted to reuse as many parts of their own windows stack as possible for this.

Basic building block of DirectX12 ist dxgkrnl.sys which stands for DirectX Graphics Kernel and may be responsible for the infamous blue screen of death, if something goes horribly wrong.

In order to use DirectX within the virtualized Linux as easy as possible they build a dxgkrnl Linux driver, that communicates with its Windows counterparts over an already established protocol.
This linux driver is just a plumbing layer, that afaik even rebuilds the Windows API

With these two drivers in place they just had to change DxCore make Linux aware and use the new Linux driver API and device that is also exposed as /dev/dxg.
Anything else including DirectX12 and user mode drivers was just a recompile for Linux, since the same API is available.

And now to the interesting bits:
Microsoft wants this dxgkrnl to be included in the mainline Linux kernel in the long run. The only way this happens is, if the Linux maintainers actually agree on merging the code base. So Microsoft has to comply with their technical demands

The DRM (the linux graphics susbsytem) maintainers already refused to merge this code, based on two things: it is not a DRM/graphics driver and more importantly they're is no open source userspace.
The latter is a hard requirement for mainline/upstream inclusion.

But other maintainers may be willing to merge the dxgkrnl as an "totally-not-gpu acceleration device" or even just Hyper-v specific device without a proper open source user space.
This happend in the past with drivers for ML accelerators by Habana Labs for example.

Mind you: Based on their decades of experience the DRM maintainers warned that this (lack of open user space) is a horrible idea.
Now even Greg Kroah-Hartman changed it's mind on that matter, and also thinks this was a bad idea.

So in order to get dxgkrnl merged into mainline Linux, the Windows devs at Microsoft will most likely have to open up (or build a open) user space for this.

That alone would imho be a huge win for open source. But it may just even get better than that.

But they will have to change the driver API itself, based on the kernel devs feedback.
With that, both the Windows and Linux dxgkrnl will probably diverge quite significantly.

It would make a hell of a lot of sense for Microsoft to not want this to happen. Easiest way to do this, is by changing their Windows driver to than more closely resemble the Linux counterpart.

So Linux development directly influencing the Windows kernel devs. Similar stuff happend with their container interfaces, so this may be likely to happen.

On top of that, so far DirectX 12 on Linux doesn't do presentation, it's just used for compute or ML acceleration.
But Microsoft is also planning to support GUI-Apps within WSL 2, and for this to work they need technology from the DRM stack of Linux

Microsoft already has a plan on how to use a Wayland server based on Weston and the sending Wayland surfaces via RDP to Windows, where they actually get painted by Windows.

For this to work they need to have quite a bit of knowledge about interacting with DRM technologies, especially dma-buf, dma-fences and stuff like synchronization and a driver.
This is apparently already build and working internally at Microsoft, as they have shown at #MSBuild

And finally, a Mircosoft employee writes
"We have consider(ed) the possibility of bringing DX to Linux with no Windows cord attached (...) DX would be running on top of DRI/DRM on native Linux.

lore.kernel.org/lkml/MWHPR21MB…

If this were to happen, there would have to be some changes to the DRM part in the kernel as well.
And as I pointed out before, this is most probably only happening with an open source user space, since this is a hard requirement.

Putting all this pieces together Microsoft will end up with not only 1,5 different linux kernel drivers (dxgkrnl and whatever they do with DRM) but also with three different DxCore user space APIs.
So far Microsoft is publicly saying they are willing to uphold this difference.

Hmm, yeah, well, IMHO this is not a proper usage of resources and not really a good idea, cause it puts a lot of burden on the maintenance of the stack.
So allow me an opportunistic look into the bright open source future at Microsofts WSL-Support.

They will realize this parallelization of effort is just a waste of time, money and resources and end up building a proper linux DRM driver that can be used in the paravirt scenario as GPU device and accel backend as well as they're Wayland backend, which can use hardware accel.

Once they reached this point they will see that now their Linux kernel driver diverged a lot from the Windows kernel driver API-wise, something they probably don't want, just to make DxCore available on Linux.

Remember in the beginning I said so far they choose a path that was as easy as possible.
If Microsoft were to truly embrace Open Source they would than just rebuild their Windows drivers and APIs to model what they did on Linux.
With this they can have a unified stack and API.

So: Open Source wins and everybody is happy.

@threadreaderapp unroll