Microsoft Announces Direct3D 12 For Linux / WSL2

[numacross]

What? That makes no sense. If the library runs on Linux it means it does NOT use DirectX.

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:

[...]
but this is *not* to introduce DX12 into the Linux world as competition. There is no intent for anyone in the Linux world to start coding for the DX12 API.
[...]

[CochainComplex]

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

[daniels]

The lib exposes the API on linux, but is otherwise not likely offering anything else of benefit that the dll wouldn't on Windows? I thought most of the work was more to do with the calls to graphic drivers / translation, but this would just be sort of like virgl wouldn't it? Just forwarding DX12 API calls to the Windows GPU drivers DX12 API to handle.

No, it's not forwarding API calls at all. It offers access to the underlying kernel driver, i.e. resource allocation + command execution + synchronisation. The DirectX implementation running in the WSL2 guest has to do all that hardware-specific work and compilation, just like direct-hardware Mesa drivers do for OpenGL.

[polarathene]

No, it's not forwarding API calls at all. It offers access to the underlying kernel driver, i.e. resource allocation + command execution + synchronisation. The DirectX implementation running in the WSL2 guest has to do all that hardware-specific work and compilation, just like direct-hardware Mesa drivers do for OpenGL.

I'll take your word for it as I can't say I understand the technicals about it myself

Just sounded like it was forwarding API calls since it required host GPU drivers and that presumably DX12 was mapping to DX12 in those host drivers. Sort of like other vGPU drivers like virtio-GPU?(I think that was it), which afaik were deferring the actual work to host drivers and just acting more as an intermediary.

Would be nice if the contribution from MS finds a way to work in the reverse, or if the support arrives without being tied to Windows host, since DX12 support in a Windows VM on linux host would be nice without having to provide exclusive GPU hardware resources to the guest for performance. Not that it would provide that out of the box, but would better allow for the possibility? (or can DXVK allow for that if we get a Vulkan equivalent of virgl?)

[polarathene]

Microsoft has laid it out with pretty pictures here if you're interested in the details.

The GPU virtualization support sounds nice. I wonder if Mesa could do similar? I am aware that Intel offers vGPU (partitioning of GPU resources which multiple VMs can leverage as their own lightweight GPU), although only seems available with AMD GPUs with more expensive SR-IOV models, no expectations for support with nvidia as they'd have to do so via their proprietary driver presumably(they likewise have similar support but only for non-consumer oriented models).

Unless the blogpost wasn't clear about the same applying there and standard Intel/AMD/nvidia consumer GPUs would not be able to leverage this functionality on Windows either?

[numacross]

The GPU virtualization support sounds nice. I wonder if Mesa could do similar? I am aware that Intel offers vGPU (partitioning of GPU resources which multiple VMs can leverage as their own lightweight GPU), although only seems available with AMD GPUs with more expensive SR-IOV models, no expectations for support with nvidia as they'd have to do so via their proprietary driver presumably(they likewise have similar support but only for non-consumer oriented models).

Unless the blogpost wasn't clear about the same applying there and standard Intel/AMD/nvidia consumer GPUs would not be able to leverage this functionality on Windows either?

What Microsoft is doing here is not really GPU virtualization. The WSL2 application will act as yet another 3D consumer from Windows' perspective. It's no different from 2 concurrent 3D applications using the GPU simultaneously. In this configuration WSL2 can consume almost 100% of the GPU resources.

SR-IOV is using hardware partitioning of the GPU into mostly independent parts. In this configuration one partition cannot consume 100% of the GPU hardware.

As for your question the only requirement on the host side is a driver that's WDDM 2.9 compatible. This depends on the manufacturer of the GPU, but I suspect any modern mainstream GPU will have support.

[vegabook]

IBM and Google need to step up to the plate here and massively stomp on this transparent attempt by Microsoft to annex Linux.

[lowlands]

IBM and Google need to step up to the plate here and massively stomp on this transparent attempt by Microsoft to annex Linux.

I would welcome it if Red Hat/IBM would buy Gitlab, opensource the enterprise edition parts and then donate it to the Linux Foundation to be the custodian, offering Gitlab for free to the World as long as the code has a proper open source license.

[polarathene]

What Microsoft is doing here is not really GPU virtualization. The WSL2 application will act as yet another 3D consumer from Windows' perspective. It's no different from 2 concurrent 3D applications using the GPU simultaneously. In this configuration WSL2 can consume almost 100% of the GPU resources.

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.

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.

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).

[tildearrow]

https://gitlab.freedesktop.org/kusma/mesa/-/commit/b3830556103b61d78567593cd656f214be8f16aa

it might be nearer than I thought

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