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.
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.
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.
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:
There seems to be a good few interesting things coming out of Build 2020. windows package management, now this
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.
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 .
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.
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.
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.