No, this is only an extension of WSL, it will not impact desktop Linux.
> This is a driver that connects a binary blob interface in the Windows kernel drivers to a binary blob that you run inside a Linux guest. It's a binary transport between two binary pieces. [...] I can see why it might be nice to have this upstream, but I don't forsee any other Linux distributor ever enabling it or having to ship it, it's purely a WSL2 pipe.
That being said I don't see why distros like Ubuntu that allow non free code wouldn't ship with it out of the box. They already support Nvidia binary drivers anyway, so why wouldn't they support a transport bridge that'd let people use them on WSL too?
Also, he notices that it's intended to be more than a bridge in the future, as they're already working on integrating it with the presentation layer on Linux.
On top of that, why would canonical care what hypervisor you're running? There's so many other cases where they haven't gone "eww.. proprietary", why would they start now.
This is a way to lock developers who want to run Linux code for AI/ML onto their windows machines and to keep them from switching their desktop OS to Linux.
Edit: from 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
Meanwhile today, Nvidia and AMD GPUs don't support SR-IOV. So that's a non-starter. It's also not clear that it the right model for GPUs either, as they have their own MMUs already.
> Kvm setups can already pass through gpus just fine.
But you need to dedicate that GPU to the guest and the host can't use it anymore.
>> > 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
From the current patch set, because they haven't hooked up the swap chains yet (as they've said that they're doing) which would allow full graphics support in the guest.
Microsoft can ship it however they please though within bounds of licenses.
And why do you assume it only helps WSL? Doesn't this help all hyper-v setups get access to GPUs, including azure?
FTR, I'm not arguing whether or not this should be upstreamed. I just see where the other poster could be coming from. I could be wrong on my take and if so, someone please correct me.
Would y'all be so worked up about VMWare upstreaming their virtual GPU bridge?
And yet here's where their paravirtualized GPU driver lives https://github.com/torvalds/linux/tree/master/drivers/gpu/dr...
It feels like they're doing everything right and everything we've asked for, for decades, and being shunned for it. What's the mechanism here for Linux winning and Microsoft being allowed into the community and what should they be doing different?
What exactly? The only performant way to expose GPUs to guests while still allowing them to be used by the host (or multiple guests) for GPUs that don't have hardware support for partitioning themselves (ie. pretty much all discrete GPUs) is to replicate the ioctl layer from the host up into the guest. Any other solution is a non starter if you care about getting the perf you'd expect from the paravirtualized GPU.