DirectX comes to Linux (via WSL2): Microsoft unveils tricks needed to flash a GPU at a penguin Microsoft has followed up the crowd-pleasing announcement of GUI and GPU-enablement for Linux apps running on Windows Subsystem for Linux (WSL) 2 with details of the tweaks needed to make the magic happen. The team has been busily developing client GPU virtualization technology over the last few Windows releases, integrating …
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/
This means that the guest needs to be able to "speak" DX12, which is why we pulled DX12 into Linux.
Nah, still don't buy it. For AI, you need CUDA. MS didn't need to expose DX12 API to Linux in order to do that, they just needed to insert a shim between Windows GPU driver and WSL that exposes CUDA. There's no need to expose DX12 to Linux.
MS's demo used a modified tensorflow that used DX12 API to access the GPU. Tensorflow shouldn't be doing that, it should just talk CUDA. This is Extend - "oh just use our API".
How do.you know? Have you asked every single Linux user? No you have not.
You have PRESUMED because YOU don't want this no one else on the entire planet won't either.
I wouldn't call someone using Linux on WSL/2 a 'Linux user'.
I wouldn't call brining DirectX to Windows WSL2 component as 'bringing DirectX to Linux' either.
agreed, OpenCL and OpenGL should be where the cross-platform development is done, and NOT some Micros~1.ONE "solution". But "Not Invented Here" for those things is driving the DirectX way of doing it.
However, if their DirectX drivers do what nVidia drivers do on Linux and BSD, that is having a GLX kernel module extension to access GPUs more efficiently via OpenGL, and the Micros~1 library gives you THAT level of performance with the SAME code on the Linux side, then I suppose what's under the hood or whatever name they give it doesn't really matter much.
The C++ extensions that Microsoft developed for parallel C++ kernels that run either on a CPU or GPU through HLSL made parallel programming much easier than OpenCL or CUBA largely through the restrict(amp) compiler directive.
The downside to C++AMP was the runtime need to use DirectX and WARP engine (for n-core CPU execution).. porting DirectX means that the C++ AMP Clang extension developed by AMD can be 100% compatible with the Windows version.
While it is tempting to say Meh, the ability to debug a kernel on a CPU is a vey valuable.
What do you mean DirectX "comes" to Linux? I've been running Windows DirectX (more properly, D3D, which is a subset of DX, but it seems to be what we are talking about here) programs in Linux for more than a year with framerates quite close to what they were in Windows on the same machine, and sometimes with more stability than the same program under Windows, strangely enough. DirectX support for Linux has been around for years longer than that, but there was a significant performance hit.
DXVK provides DirectX at near Windows native speed for Linux, while WINE makes the Windows programs that use DX work in the first place. That's DX in Linux, and it is not new, nor was it a product of Microsoft. Things like WINE, DXVK, Samba, etc., exist in spite of Microsoft's efforts, not because of them.
Adding DX to WSL is merely bringing DX to a part of Windows that didn't have it before... hardly justifying the headline. Let's not give them credit for bringing DX to Linux when they've done nothing of the sort.
Relative power in the computer industry has always been assessed by looking at the party/ies making the moves to close the gap. Thus it was easy back in the tail end of the nineties to see that Linux was catching up with Unix and passing it, by the number of Unix suppliers offering Linux compatibility with their Unixen.
Microsoft is now putting in the effort to catch up with Linux on its Windows platform. How the mighty have fallen. It's an admission. The next thing I for one want, is the source trees of obsolete MS Windows OSes, system development tools, and productivity tools under the GPL or something equivalent, with "software patent" protection, so everybody can play around with them. It's what's happened with early Unix.
The very next step in the DirectX thing will be to incorporate it into the X Window System tool chest, of course, and sooner or later, porting games to Linux and thus gaming on Linux will be so much easier.
I'm not saying they should or shouldn't but Microsoft do like their backward comparability though they have said that Windows 10 will be the last Windows: https://www.theregister.co.uk/2015/07/31/rising_and_ongoing_cost_of_windows/
Maybe we misinterpreted it and they are ditching it in favour of going back to their roots? I like the name Xenix, it's definitely cooler than Windows and Linux style performance in gaming is attractive.
Personally, I would be happy if Windows 10 could update without crashing at around 90%.
Yes, I have done every damn thing that they suggest, DISM, and on and on.
It becomes like watching paint dry.
My Linux triple boot efforts work just fine.
And they update like clockwork, without any problems.
MS might attempt to sell camels to Arabs, and fridges to Eskimos, but until their basic system actually
works, they may as well sell used cars.
And we all know how that works. !?!
"How do.you know? Have you asked every single Linux user? No you have not.
You have PRESUMED because YOU don't want this no one else on the entire planet won't either."
But, they're right, no Linux user will want this. If they are providing OpenGL and CUDA (and preferably OpenCL and Vulkan) via a "guest addition" video driver that's converting everything into DX12, fair enough, with no physical video card in a VM the driver has to be doing something and that's a reasonable thing to do when the goal is to use a GPU in Windows. But, it's truly WSL2's job to provide OpenGL and CUDA interfaces in Linux if they are claiming Linux GPU acceleration; it's in no way the programmers job to rewrite their fully functional code just to support a single VM system.
That said.. I don't even think Microsoft is expecting Linux users to use DX12 (I sure hope not!), i think this is likely a proof of concept (getting tensorflow up under it is not a bad start...) and they'd ultimately have normal OpenGL and CUDA support in WSL2.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
