Looks like WSL capabilities are expanding, it’s going to be possible to run accelerated Linux applications under WSL. Helluva tool for developers as it’s shaping up. But if this finds it’s way to upstream Linux, it might enable porting of applications that were previously a huge no-no. Microsoft ought to contribute this to Linux/GNU to make any sort of impact IMO, but it seems dx12 will stay a binary blob nonetheless. No idea what it means for the driver situation though.
Binary blob will be the biggest blocker to Kernel adoption. It’s like if Nvidia asked for their proprietary firmware for their newest cards to be included in the Kernel, while still maintaining copyright and patents to closed source code.
https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-DXGKRNL-Uphill-Battle
It’s literally like the Nvidia Proprietary driver situation. I doubt it will mainline because it requires WINDOWS to run, and redistributing stuff from Windows that isn’t publicly available is illegal. Just look at Valve’s stance on the illegal Media Foundation fix for Wine.
Also, this is exactly what I feared would happen to exFAT, just ended up happening to DX12. BTW, the exFAT patents are still not surrendered to the OIN (Open Invention Network) yet for current implementations, (only future implementations) so MS still holds them on legacy software. YES, there’s still a gotcha.
Microsoft’s statement is related to future versions of the Linux Kernel. So for (a), an OEM using an external exFAT driver is not covered under that exFAT specifications (GPL v2) announcement by Microsoft. As of today (March 2020) there is no legal way for an OEM to distribute Linux products that support exFAT without obtaining a proper license for Microsoft exFAT technology.
3 Likes
No, it is not. The kernel module is open source, i.e., part that is in the kernel is open source.
The problem with upstreaming is that everything surrounding it is closed so the Linux devs don’t want to support it. It is not that they are putting proprietary code in the kernel.
2 Likes
The problem is the d3d12 library which is only available in Windows, and won’t be available in any other way.
My Media Foundation argument stands. If you copy a DLL from Windows simply to get this working, it’s illegal.
Even if it’s integrated, it’s useless on real distros, only in WSL.
Liam got the right idea on this:
2 Likes
There seems to be a good few interesting things coming out of Build 2020. windows package management, now this 
1 Like
Yes, absolutely.
I guess I just misunderstood what you were saying. I thought that you were saying upstreaming the module would be illegal as it is closed source and proprietary.
Doing some digging, they seem open to possibly opening it up a bit more.
https://lore.kernel.org/lkml/CAPM=9tx4wh-Lk6Dffsdh-7mYvXx+GX2AxhrGqFgyN8-AWJvP6A@mail.gmail.com/T/#t
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
3 Likes
The only thing I could see massive benefits for is Stadia. Google can license DirectX for native DirectX on it’s Linux VMs since Vulkan adoption hasn’t hooked many devs for Stadia.
Being unable to know what Stadia code looks like, they can add proprietary modules and no one would be the wiser because by nature it’s a closed ecosystem.
It’s more than likely written in Go.
3 Likes
Pfft. Fitting.
Neural Nets are basically 3D Go.
its a trap
if it wasn’t a trap, Microsoft would just be offering a simple way to port/run Direct3d to Vulkan (e.g., by contributing to vkd3d, etc.) and supporting Vulkan on windows.
1 Like
Same way Epic will never optimize Vulkan for Unreal Engine, and will never put it on Windows.
To be fair, that would not achieve what they are looking for - a Linux tool set under Windows. That would just benefit users that run Linux natively.
EDIT: To elaborate. They still need the Windows kernel to be in charge of the system. To enable Vulkan in this situation would require a specific pseudo-device driver that is probably not going to get merged in the Linux kernel. That will also require changing their DX12 implementation drastically. Which is what they are trying to avoid with this. That’s why the layer “resembles Windows”. It’s the minimal amount of work to get to where they are.
But I agree that their intents are egoistical. That does not benefit the Linux community much.
EDIT2: They’re not really going to reimplement WINE/DXVK either.
I feel that this rather belongs into Mesa alongside other graphics APIs like OpenGL and Vulkan. This could in turn hook into some sort of virtual GPU, for which an open source driver would have to be written.
Microsoft pushing nvidia to contribute to the linux kernel and opensource community 
All for a sweet little bite of that cloud pie!
Long live the cloud! 
1 Like
Unfortunately, it’s an argument that it will never happen. Because something that only functions with a proprietary support is not gonna get into the Kernel that easily.
I’m going to stay optimistic and excited for the feature. As much as many people like to be cynical about M$ supporting GNU/Linux, given the support for work done through WSL 2. This seems to be a step in the right direction
There seems to be a change in company culture. However the moment M$ starts to revert to their past selves, I am sure the cynical crowd will be first to call them out.
Until that happens, I remain excited to see how much futher they will contribute to the GNU/Linux Project
I don’t think it will, either 
And if it is as it seems it is, I really don’t think anyone will give a shit about directx in wsl, since Microsoft wants it to work for virtualized compute applications, a hyperv host hosting a bunch of linux vms that get the privilege of accelerating some compute tasks through a software virtualized gpu, and at the same time, no support for any other setup that could benifit gaming.
Well they want a foot in the cloud, understandably, obviously they can’t compete with linux on compute layer os, they are trying to compete at the hypervisor level, (mainly with vmware) and application level (with everyone), take sqlserver for linux as an example, or dotnet core framework. They are playing fair, I guess. Dotnet core is a great framework and completely opensource, sqlserver is not opensource, nothing’s wrong with that (unless your name is Richard Stallman), you get to choose your own poison, but in the case of directx, nah not a lot of people will choose that.