5 ms·

Thank you. In the meantime I also noticed the following comment from Dave Airlie on LKML [1]: > This is a driver that connects a binary blob interface in the W

by 4cao 6y ago

Thank you. In the meantime I also noticed the following comment from Dave Airlie on LKML [1]: > 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. 1. https://lkml.org/lkml/2020/5/19/1288 https://lkml.org/lkml/2020/5/19/1288

monocasa 6y ago
He's pretty against it on a number of fronts. 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.
- kelnos 6y ago
  Why would they? In its current state, this driver is only useful when Linux is running on Windows. A regular Linux desktop/server user would not find this useful.
  - monocasa 6y ago
    Azure is more than 50% Linux. There's an incredible amount of "regular" Linux instances running on top of hyper-v. This lets them use a virtualized GPU in that env. 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.
    - isatty 6y ago
      I don’t think azure is relevant here. Standardizing SR-IOV would be much more helpful to everybody (but much more important to Azure/cloud platforms). Kvm setups can already pass through gpus just fine. 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
      - monocasa 6y ago
        > I don’t think azure is relevant here. Standardizing SR-IOV would be much more helpful to everybody (but much more important to Azure/cloud platforms). 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.
- isatty 6y ago
  Because this benefits only WSL. I don’t think that the Linux maintainers should spend time and effort maintaining a shim that only benefits users on another operating system. It does not even lead to cross platform code if a dev uses this on WSL. Microsoft can ship it however they please though within bounds of licenses.
  - monocasa 6y ago
    They've already upstreamed lots of other hyper-v paravirtualization infrastructure. And why do you assume it only helps WSL? Doesn't this help all hyper-v setups get access to GPUs, including azure?
    - vopi 6y ago
      Probably because its a shim to use a proprietary (only distributed by MS) binary blob version of DirectX compiled for Linux. Outside of ML utilizing DirectX in WSL on Windows, the only group that this helps is MS. 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.
      - monocasa 6y ago
        They also ported OpenCL and OpenGL to it via Mesa. Vulkan is in the works, and you can use CUDA if the host GPU supports it. Would y'all be so worked up about VMWare upstreaming their virtual GPU bridge?
        chrsw 6y ago
        Depends. If VMWare had the history Microsoft had one would be naive not to get "so worked up".
        monocasa 6y ago
        VMWare is probably the company with the worse reputation than Microsoft since they spent more than a decade shipping large part of Linux linked against their proprietary hypervisor in a blatant GPL violation. And yet here's where their paravirtualized GPU driver lives https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/vmwgfx https://github.com/torvalds/linux/tree/master/drivers/gpu/dr...

by 4cao 6y ago

monocasa 6y ago

He's pretty against it on a number of fronts. 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.

kelnos 6y ago
Why would they? In its current state, this driver is only useful when Linux is running on Windows. A regular Linux desktop/server user would not find this useful.
- monocasa 6y ago
  Azure is more than 50% Linux. There's an incredible amount of "regular" Linux instances running on top of hyper-v. This lets them use a virtualized GPU in that env. 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.
  - isatty 6y ago
    I don’t think azure is relevant here. Standardizing SR-IOV would be much more helpful to everybody (but much more important to Azure/cloud platforms). Kvm setups can already pass through gpus just fine. 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
    - monocasa 6y ago
      > I don’t think azure is relevant here. Standardizing SR-IOV would be much more helpful to everybody (but much more important to Azure/cloud platforms). 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.
isatty 6y ago
Because this benefits only WSL. I don’t think that the Linux maintainers should spend time and effort maintaining a shim that only benefits users on another operating system. It does not even lead to cross platform code if a dev uses this on WSL. Microsoft can ship it however they please though within bounds of licenses.
- monocasa 6y ago
  They've already upstreamed lots of other hyper-v paravirtualization infrastructure. And why do you assume it only helps WSL? Doesn't this help all hyper-v setups get access to GPUs, including azure?
  - vopi 6y ago
    Probably because its a shim to use a proprietary (only distributed by MS) binary blob version of DirectX compiled for Linux. Outside of ML utilizing DirectX in WSL on Windows, the only group that this helps is MS. 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.
    - monocasa 6y ago
      They also ported OpenCL and OpenGL to it via Mesa. Vulkan is in the works, and you can use CUDA if the host GPU supports it. Would y'all be so worked up about VMWare upstreaming their virtual GPU bridge?
      - chrsw 6y ago
        Depends. If VMWare had the history Microsoft had one would be naive not to get "so worked up".
        monocasa 6y ago
        VMWare is probably the company with the worse reputation than Microsoft since they spent more than a decade shipping large part of Linux linked against their proprietary hypervisor in a blatant GPL violation. And yet here's where their paravirtualized GPU driver lives https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/vmwgfx https://github.com/torvalds/linux/tree/master/drivers/gpu/dr...