16 ms·
> This also enables third party APIs, such as the popular NVIDIA Cuda compute API, to be hardware accelerated within a WSL environment. Dollars to donuts this
by _vbdg 6y ago
> This also enables third party APIs, such as the popular NVIDIA Cuda compute API, to be hardware accelerated within a WSL environment.
Dollars to donuts this is why Microsoft is implementing this. GPU acceleration is becoming a critical feature for many users (but especially developers) and this will continue. If WSL is to be a serious competitor, this is necessary and I'm glad to see it showing up. This is true of cloud compute, too, and Microsoft is betting big on cloud as its future growth area.
> Only the rendering/compute aspect of the GPU are projected to the virtual machine, no display functionality is exposed.
The Linux gaming folks will be pretty sad about this one. Anyway, this isn't really a Linux port of DirectX. This is GPU compute via DirectX APIs.
So now, I'm just waiting on monitor mode/AF_PACKET for WSL...
- Mic92 6y agoDo ML people actually care about DirectX? I thought everyone is using CUDA? Anyway in my university building I have not seen anyone that does machine learning on Windows.
- modeless 6y agoCUDA is supported as well.
- raphlinus 6y agoYes, (almost) everybody doing machine learning is on CUDA. There are multiple pieces of this work, and the DirectX API's are only part of it. Other pieces get CUDA running as well. And yet another piece is a layer to get OpenGL and OpenCL workloads running on DX12 as well, rather similar in scope to how MoltenVK and the gfx-hal Vulkan Portability work are a layer to get Vulkan workloads running on Metal. This is a big effort, and it seems to me their goal is to get things to the point where stuff Just Works and you don't have to think too hard about the various bits of (technically difficult!) infrastructure to get you there.
- cududa 6y agoA bit of a tip, your university development experience is not going to be like anything you see in production
- anaisbetts 6y agoThey typically don't - the team published both a special build of Tensorflow that uses DirectX, as well as working with nVidia to get CUDA running against their DX Linux kernel implementation
- lostmsu 6y ago> special build of Tensorflow that uses DirectX Huh? Are you sure about that? Regular TensorFlow on Windows uses CUDA, not DirectX-flavored compute.
- deleted 6y ago[deleted]
- numpad0 6y agoIn ML if you decide not to kiss NVIDIA's ass you're screwed. Figuratively they have 100% market share. Having major alternative backend, even if it's proprietary, will force diversity and that has some upsides I think.
- raphlinus 6y agoThe associated blog post (https://devblogs.microsoft.com/directx/directx-heart-linux/ https://devblogs.microsoft.com/directx/directx-heart-linux/) does have more details on exposing display functionality. There is no swapchain functionality yet, but it's clear they're working on it, and part of the work is "DxCore", which seems to be a cleaned up and simplified version of DXGI. So not now, but soon.
- chenzhekl 6y agoYeah, this should be the right link. TL;DR Microsoft brings DirectX 12, OpenGL, OpenCL, and CUDA to WSL. Vulkan is under investigation. That's really a piece of exciting news!
- dang 6y agoWe've changed to that from https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742. Thanks!
- modeless 6y agoYes, machine learning is the first priority as they say in the thread. However, the blog post goes on to say that window system integration is coming. This will eventually be a full graphics stack. > Anyway, this isn't really a Linux port of DirectX The entire user mode side of Direct3D is ported, in addition to the user mode parts of the Nvidia, AMD, and Intel graphics drivers.
- deleted 6y ago[deleted]
- pier25 6y ago> This will eventually be a full graphics stack Are we seeing the start of the migration of Windows to linux?
- sandworm101 6y ago>> the migration of Windows to linux Please no. Please keep your peanut butter out of my chocolate. Call me a purist, but linux should take nothing from windows, give no ground, make no compromise. One must die for the other to live. https://bugs.launchpad.net/ubuntu/+bug/1 https://bugs.launchpad.net/ubuntu/+bug/1
- agildehaus 6y agoChocolate and peanut butter are pretty good together. Just sayin'.
- dgellow 6y agoWait, is chocolate and peanut butter really a thing?! That sounds quite horrible to my non-US ears. Edit: yep, an online search seems to say that's an actual thing. I guess I'm part of the ten thousand today https://xkcd.com/1053/ https://xkcd.com/1053/. I will never understand the US fascination for peanut butter.
- 6y ago
- miffe 6y agoThey are also adding an wayland server. https://devblogs.microsoft.com/commandline/the-windows-subsystem-for-linux-build-2020-summary/#wsl-gui https://devblogs.microsoft.com/commandline/the-windows-subsy...
- ghostpepper 6y agoAren't large parts of the wayland stack incompatible with NVIDIA drivers? It would be ironic if Microsoft was the one to bridge that gap.
- microcolonel 6y agoThat's more a matter of buffer management. Though it may turn out , if their work is too tied to NVIDIA, to only support NVIDIA's de facto proprietary selection: EGLStreams. Though in principle, there's nothing preventing them from using GBM instead of EGLStreams, and there are some good practical reasons such as having compatibility with the broad base of existing accelerated Wayland windowing libraries and applications.
- josefx 6y agoYou can use Wayland with NVIDIA drivers. The problem is that NVIDIA and the open source drivers expose different buffer management APIs and Wayland does not abstract over that, so it has to be explicitly handled by every client application. Some Wayland clients refuse to support both, others had NVIDIA support patched in by NVIDIA itself.
- dcgudeman 6y agoSorry if this question misses the point but how did AMD avoid this issue? Are their drivers open source?
- josefx 6y agoAMD started to support the development of the open source driver several years ago by publishing hardware specs. . I am not sure if they switched completely or are still maintaining a closed source driver on the side - I haven't bought AMD cards in years, my last one only "works" with the binary blob. The people working on the NVIDIA open source driver have no official support and were fighting with signed firmware blobs last I heard. I wish them luck, but even on older cards it is more likely to crash your system than render anything.
- deadbunny 6y agoYup, from one of the MS staff replies further in the thread[1] > 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. Can't say I can get behind MS trying to shift maintenance for a Windows only "feature" onto the Linux devs here. 1. https://lkml.org/lkml/2020/5/19/1139 https://lkml.org/lkml/2020/5/19/1139
- Wowfunhappy 6y agoIs there a possibility Linux upstream won't accept it?
- cdash 6y agoSure, but that doesn't really stop Microsoft from achieving their goal with WSL2. They would be happy to upstream it if possible if not then oh well.
- detaro 6y agoThat's pretty much always a possibility. On the other hand, they're also generally fairly open to add things as long as the developers react to concerns. I'd guess if this can be neatly stuffed in a corner and treated like any of the other Hyper-V specific drivers, and quality is okay, it has a reasonable chance to be accepted. And if it is rejected, Microsoft can still ship it in the kernels for the distros they offer on WSL.
- rezonant 6y agoYeah not the end of the world if it doesn't land immediately, based on the original devs responding that they'd rather find the right place for it than the expedient place for it
- kelnos 6y agoIf you read the replies by Dave Airlie and Daniel Vetter, it seems somewhat likely that upstream won't accept it. Perhaps that's just initial skepticism that will evaporate after more discussion, but perhaps not. Frankly this does just seem like MS wanting to reduce their maintenance burden on what they expect will be a very important part of their WSL offering on Windows. There's nothing inherently wrong with that desire, but the people on the other side need to weigh their maintenance burden[0] with what benefit this will have to the Linux community as a whole, which at first blush seems minimal. Especially considering that the userland pieces that talk to this driver aren't open-source. There's also the question of whether or not you believe WSL as a whole is good or bad for Linux. If there are people who would run a Linux desktop for development who then decide not to because WSL exists, perhaps that's a bad outcome. If you have people writing more DirectX GPGPU code who would otherwise write to a standard interface like OpenCL, perhaps that's a bad outcome (to be fair, there's also a lot of CUDA out there, which is similarly problematic). Is this the start of MS going back to their "Embrace, Extend, Extinguish" playbook, or is that just a paranoid fear? They've definitely been embracing Linux, and enabling people to write DX12 GPGPU code that targets a Linux environment but will only run under WSL on a Windows install does feel like "extend". I'm not sure where I personally stand on this issue as I haven't done my research, but I think they're interesting questions to ask. If this gets rejected, of course it doesn't stop MS from doing any of these things, but it does make it harder for them to maintain their extensions to Linux. [0] Airlie is even concerned that just by looking at the code, he or other DRI developers could run into future IP derived-works trouble when designing future Linux graphics interfaces.
- improv32 6y ago> AF_PACKET Just run a Linux hyper-v vm. That's what WSL2 is doing under the hood anyway. I run it this way and it's great. I have windows terminal auto ssh into it. Performance is great. And using the X server x410 on the windows side gui performance is fantastic (though no hardware acceleration) because instead of ssh tunneling x410 suports AF_VSOCK for the x socket, which hyper-v supports for performance as good as a domain socket on the same machine.
- mauflows 6y agoI've had trouble researching if WSL2 is in fact a hyper-v managed VM. I've seen some documentation referring to WSL2 as a tightly integrated Krypton (scaled down hyper-V) VM. It seems to imply the host overhead isn't as high as a guest on hyper-V
- monocasa 6y agoAFAICT Krypton is stripped down in the sense that a lot of the management framework is gone, but as far as the guest is concerned, it's running on hyper-v.
- bitcrazed 6y agoWSL uses a Hyper-V derived virtual machine that is * Sparse & light - they only allocate resources from the host when needed, and release them back to the host when freed * Fast - it can boot a WSL distro from cold in < 2s * Transitional - these lightweight VMs are designed to run for up to days-weeks at a time Full Hyper-V VMs aim to (generally) grab all the resources they can and keep hold of those resources as long as possible in case they're needed. Full VMs are designed to run for months-years at a time. WSL's VMs are MUCH less impactful on the host - FWIW, I run 2-3 WSL distros at a time on my 4 year old 16GB Surface Pro 4 and don't even notice that they're running.
- mauflows 6y agoBut then you have this thread with people running Cron jobs to free cached memory: https://github.com/microsoft/WSL/issues/4166 https://github.com/microsoft/WSL/issues/4166 I imagine this will be addressed, but claims of lightweight seem exaggerated? But even more on my mind is the impact on the windows host. Is it running as a guest under hyper v? What's the overhead?
- Phylter 6y ago"There is currently no presentation integration with WSL as WSL is a console only experience today. The D3D12 API can be used for offscreen rendering and compute, but there is no swapchain support to copy pixels directly to the screen (yet )." This leads me to believe that display support is intended in the future. It's a work in progress. They've gone this far why would they stop at compute? Still, it's pretty awesome if you ask me.
- dragonwriter 6y agoThey've announced that Linux GUI apps are coming later this year to WSL2; while that is possible without GPU, I imagine MS wants a decent UX for the feature, though, which suggests...
- castis 6y ago> The Linux gaming folks will be pretty sad about this one. I was a tad bummed when realizing what this actually was, but still very much impressed.
- discordance 6y agoAh that sucks, for a moment I thought I would be able to run Wine from within WSL2 and get my game on.
- navanchauhan 6y agoif you are already running Windows and using Linux through WSL, why would you want to use WINE to run games?
- Zardoz84 6y agoAnd wouldn't be faster simple use native Linux installed on the computer ? Instead of running on a VM, and a glue/translation layer from OpenGL/OpenCL/Vulkan/CUDA to DirectX. And don't forgot all the blotware and slowness that have Windows 10.
- dividedbyzero 6y agoBut then you lose all the benefits of an established desktop OS, like all hardware pretty much working, the OS pretty much working out of the box, plus software like Microsoft Office just runs without any additional effort, plus you get to profit from years or decades of muscle memory and OS-specific knowlegde, and maybe it's even about being allowed to connect your laptop to the company networks at all.
- jamesgeck0 6y agoSpeaking as someone who spent like a dozen hours trying to get his duel monitor setup working in Ubuntu and Fedora: no. It's not. My experience is that Linux has significantly worse hardware support than Windows, particularly where newer hardware is concerned.
- srg0 6y agoGaming folks won't be running games in WSL when they can just run them in W.
- deleted 6y ago[deleted]