Microsoft Announces Direct3D 12 For Linux / WSL2

[bemerk]

I bet Microsoft forced FreeDesktop to work on the DirectX 12 bits.

It is Collabora and MS mostly that commits on that branch. So nothing wrong with good old paid work.

[tildearrow]

It is Collabora and MS mostly that commits on that branch. So nothing wrong with good old paid work.

Yep, I know paid work is not wrong, but had they not accepted to do this, then Microsoft would have not tried Extend on us.

[numacross]

I thought I had read an MS dev on the mailing list say something about using DX12 to handle GPU partitioning or something, perhaps they meant all applications running on WSL would appear as a single application using GPU on the host, I dunno.

It's the same kind of partitioning that happens between for example two 3D applications on Windows. I'm pretty sure that different applications from WSL2 will appear separate in Task Manager and Performance Counters. From the perspective of the Windows GPU drivers they are "just D3D clients".

If the performance is good though, as in native or close to for the GPU that's still the desired outcome, which is lacking for linux as a host with KVM/VBox/VMWare guests with their vGPU drivers, only option is to provide exclusive direct access to a guess with VFIO. The article you linked had mentioned Hyper-V and passthrough iirc, which gave the impression the performance is going to be much nicer than a VM guest.

Depending on the used VM technology performance is already near-native. However this entire thing, for the moment, is not capable of rendering anything - it's just compute on GPU.

If so, then Windows can offer easy/decent performance of linux via WSL2(not 100% sure if they've resolved the disk I/O perf issues yet), whereas Linux can sort of do that with WINE/Proton but it's presumably not as stable as Linux on Windows(I can't seem to get wine-staging to recognize CUDA anymore for a windows only app I'd like to use on linux for example, it's Qt GUI is also a bit buggy via WINE). If they do go ahead with allow linux distros to use the DX12 lib without needing a windows host, perhaps that'd improve the Windows compatibility(though I assume the bugs I experience are unrelated to that).

Microsoft did allude that they will bring DX12 to Linux eventually (can't find the link - I saw it in one of the kernel mailing lists), but at the moment what this article is discussing is not capable of rendering anything, not even 2D.

[nuetzel]

Further D. Airlie reply btw nice nvidia sidenote https://lists.freedesktop.org/archiv...ay/266697.html

Only remark, your link point to Daniel Vetter (Intel).

[L_A_G]

That should also allow for more adoption of Windows instances in Azure over Linux presumably. They offer linux instances with Azure, but I assume they survey users for why they choose linux over windows instances on the Azure service and seek to minimize those reasons as much as possible.

Running VMs in a "cloud" (read:VM) service? That very much reminds me of meme from way back when centering around a rapper who hosted a "reality" TV program:

"You dawg, we heard you like VMs so we put a guest OS running a VM instance of the host OS running applications of the guest OS so you can run Windows applications in a Linux VM running under a windows VM running under a Linux host OS"

If that was confusing, then don't blame yourself because this really is mindbogglingly stupid and over-complex. Kind of reminds me of the babel fish god argument from the Hitchhiker's Guide to the Galaxy. An Azure instance running this would start out with the Azure's main Linux-based host OS running a Windows guest. This windows guest would then have a Linux guest VM, i.e another instance of the host OS, and running applications for the windows, i.e original guest, OS under it.

Maybe I should fire up GIMP and make a meme image macro of this... It won't make this any clearer, but at least it'll be a bit funnier.

[sarmad]

I never said the library will use DirectX directly. If said library uses CUDA/OpenCL then it will use Direct3D to get to the GPU via this entire elaborate shim setup. Microsoft has laid it out with pretty pictures here if you're interested in the details.
They do not intend Linux developers to use Direct3D directly and even said so on the mailing list:

Thanks for the clarification. What a misleading announcement. Then this really has nothing to do with adding DirectX to Linux/WSL, it's merely just about enabling hardware acceleration in WSL. It just happened that this hardware acceleration will be done by mapping OpenGL/Vulkan/OpenCL/etc in the guest to DirectX in the host. Basically the reverse of DXVK.

[mdedetrich]

- win10 is giant slow and bloated piece of crap
- win10 is a spyware
- NTFS is slow

Every point apart from the last one is false and a filesystem being slow is hardly a reason to entirely move to another OS.

The only people I see moving to Linux are developers coming from MacOS because they got fed up with Mac for some reason (crappy hardware and the MacOS going to shit).

[mdedetrich]

I also find it hilarious how people just read the headline and didn't bother reading the article properly.

What Microsoft is doing is mapping Vulkan/OpenGL/CUDA calls to DirectX, thats it. They are not exposing DirectX to linux directly or anything along those lines.

If anything this is great for Linux because it greatly improve Vulkan/OpenGL/CUDA interopt with DirectX which is what DXVK does (just in reverse). Microsoft is just designing a shim ffs.

[skeevy420]

Steve Pronovost
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 😊.

It's been around 18 hours. Has enough time passed

[JustinTurdeau]

Every point apart from the last one is false

Found the Microsoft shill.