DirectX comes to Linux (via WSL2): Microsoft unveils tricks needed to flash a GPU at a penguin
- Reference: 1589982787
- News link: https://www.theregister.co.uk/2020/05/20/microsoft_directx_wsl_linux/
- Source link:
The team has been busily developing client GPU virtualization technology over the last few Windows releases, integrating the toys into the Windows Display Driver Model (WDDM) from version 2.5 onward.
Referred to as WDDM GPU Paravirtualization (GPU-PV), the tech had been limited to Windows running in a VM or container, but with WDDM 2.9. the team is extending a hand to Linux guests via a new Linux kernel driver to expose GPUs to Penguistas.
It's a neat trick. The new driver, [2]dxgkrnl , mimics the native WDDM D3DKMT kernel service layer on Windows and uses the VM bus connection to get at the GPUs. "There is," [3]said Microsoft , "no partitioning of resources between Linux and Windows or limit imposed on Linux applications."
Microsoft has also made the code of the [4]driver open source , and insists that the Linux dxgkrnl is a "clean room implementation."
The change has also meant that the Redmond gang has been able to bring the DirectX API to Linux (in WSL2) as well. "This," boasted the Windows giant, "is the real and full D3D12 API, no imitations, pretender or reimplementation here," although it does admit that there is no presentation integration as yet. WSL is, after all, a console experience. While the D3D12 API is good for offscreen rendering, those pixels cannot, as yet, be flung onto the screen.
As well as D3D12, Microsoft has also ported its machine learning API, DirectML and is working on OpenGL and OpenCL to WSL. Support for CUDA in WSL 2 will also turn up in NVIDIA's WDDM 2.9 driver. The gang is, however, remaining tightlipped about its plans for Vulkan.
Microsoft was also uncharacteristically open about when Windows Insiders would get their mitts on the new toys. Fast Ring Insiders are currently on the Manganese (Mn) branch and can expect support for DxCore, D3D12, DirectML and NVIDIA CUDA to arrive in June, when the Fast Ring should switch to the Iron (Fe) branch.
Support for GUI applications and the long wished-for [5]Year of Linux on the Desktop will come a little later. ®
[1] https://www.theregister.co.uk/2020/05/19/wsl2_gui_linux_apps_windows/
[2] https://lkml.org/lkml/2020/5/19/742
[3] https://devblogs.microsoft.com/directx/directx-heart-linux/
[4] https://github.com/microsoft/WSL2-Linux-Kernel/tree/linux-msft-wsl-4.19.y/drivers/gpu/dxgkrnl
[5] https://theregister.co.uk/2019/05/06/windows_subsystem_for_linux_terminal/
Kind of handy that my monitor is 4K plus a bit extra on the side then. Whilst it isn't great, at least VirtualBox doesn't crap itself for me.
Why the fuck would you do this? So you want to expose the native GPU to linux from WSL? Absolutely fine. We need CUDA and we need OpenGL. Are there thousands of linux apps begging for DirectX support? No there are not. Why would you add this layer? (apart from the obvious: its "Extend" time)
To quote one of their developers when this came up on the kernel mailing list:
"There is a single usecase for this: WSL2 developer who wants to run
machine learning on his GPU. The developer is working on his laptop,
which is running Windows and that laptop has a single GPU that Windows
is using.
Since the GPU is being used by Windows, we can't assign it directly to
the Linux guest, but instead we can use GPU Partitioning to give the
guest access to the GPU. This means that the guest needs to be able to
"speak" DX12, which is why we pulled DX12 into Linux."
https://lore.kernel.org/lkml/20200519203608.GG33628@sasha-vm/
Better than the crap video in Virtualbox... hell, the latest Virtualbox craps itself when it sees a 4K monitor.