17 ms·

Yup, 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 GP

Yup, 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 ago
Is there a possibility Linux upstream won't accept it?
- cdash 6y ago
  Sure, 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 ago
  That'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 ago
    Yeah 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 ago
  If 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.
  - kbenson 6y ago
    > 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. I think if that really matters you should be against anything in the kernel to make it work well as a VM under Windows or MacOS or BSD, and in VMware or VirtualBox too. From that point of view, Linux in a VM on another host is taking away from Linux running as a desktop on that host. Linux running as a VM on a VMware cluster is taking away from Linux running on those bare metal servers instead of VMware ESXi. I think the more sane way to look at it is that Linux is an application (and its subcategory is that it is an OS) which is meant to run on various hardware and software platforms, the more the better. This strategy has worked very well over that last couple decades. Does allowing WSL mean that some people that would install Linux on their hardware just run Windows instead and use Linux on top? Probably. Does it mean that people that already ran Windows and have never used Linux get exposed to it for the first time and get familiar with it through a few click on their existing Windows computer? That's also probable. Does it really matter in the end? Probably not.
    - yuribro 6y ago
      > I think if that really matters you should be against anything in the kernel to make it work well as a VM under Windows or MacOS or BSD, and in VMware or VirtualBox too. Why? I would guess that a very large share of linux kernels run under a hypervisor in some data center, in a public cloud or some OpenStack cluster. Won't those mostly be the same features?
      - TeMPOraL 6y ago
        Because WSL doesn't compete with people who would otherwise run a Linux box, it competes with people who would otherwise shove Ubuntu into a VirtualBox and run it on their Windows box in seamless mode. So the idea that it drives people away from Linux proper is nonsense (BTW., WSL is Linux proper), unless you also believe that installing a Linux in a VM on a proprietary system is also driving people away.
- Iv 6y ago
  Why would it? That's a functionality that can't be used without Microsoft proprietary parts. Unless I missed something, I don't think there is an open source implementation of DirectX somewhere? I doubt the linux devs ever see WLS as a target they have to maintain themselves.
  - nitrogen 6y ago
    Wine has an open source implementation of DirectX, FWIW.
    - Iv 6y ago
      Ok, not my field, but isn't it based on OpenGL? Does it count as an implementation or an emulation layer? My understanding is that Microsoft is trying to give WSL a transparent access to the GPU using the regular linux interface and transmitting it to DirectX. Using that with wine would mean adding two emulation layers before reaching the actual driver. I fail to see any use case for that.
      - traverseda 6y ago
        It's based on vulkan, which means that it has low enough level access to the GPU that I think it's fair to call libraries implemented on top of it "native". Most GPU drivers have some kind of translation for directx already, and there's no inherent reason why the open source directx implementation has to perform worse than the GPU implementation of directx. I hear that the open source dx11 implementation actually beats AMD's DX11 implementation in some cases. So yeah, vulkan is neat and opens up a whole lot for the linux world. In the future you'll probably see userspace implementations of opengl on top of vulkan, maybe even CUDA implemented on AMD gpus, although I'm not sure how practical that is. Also a whole lot of exciting GPU sharing tech, accessing GPUs inside of VMs for example. DirectX will come to linux, but it won't be thanks to microsoft. You can thank valve hedging their bets on the microsoft store for that.
- bubblethink 6y ago
  What would be the big loss other than MS bundling a ppa ? Nvidia drivers and cuda anyway need a ppa. So wsl + nvidia + cuda being a single ppa is anyway not that far off.
lostmsu 6y ago
To be honest I don't quite understand what stopped those developers from running machine learning on their GPUs under Windows itself. Most frameworks work just fine. I've been doing quite a lot of TensorFlow with both Python and .NET. The only time I faced the need for Linux box is trying a demo project from OpenAI, which did not use the features it required Linux for on a single machine anyway.
- rezonant 6y ago
  I believe the purpose is for devs who are deploying to Linux, their toolchain may not fully work in Windows, but they want to have a similar dev/test env within Windows... pretty much the whole point of Windows Subsystem for Linux (WSL). It's not that the frameworks don't work on Windows, it's the deployment tech, like Docker, Ansible, their build scripts etc etc. Some users may be doing something totally custom on top of the GPU without a framework layer but that is probably very few users. I'd have to guess though that those users would be the type of users that would get MS to go through the effort though...
  - lostmsu 6y ago
    Do people actually use Docker and Ansible a lot for ML??? Doing something custom on top of the GPU is also not much different on Windows, than Linux. CUDA is basically the same. OpenCL and Vulkan are available too. I'd like to hear perspective of a person, who actually does ML specifically on Linux for some reason.
    - hetspookjee 6y ago
      Well CUDA is only one thing. Especially in the python environment it's only a matter for time before you run in some wierd dependency issue that is Windows only. For example, getting XGBoost completely up and running on Windows requires you to either build it yourself or download a .dll from a university link. Installing it on Linux is just a proper pip install. Also windows not having a build in C compiler makes you dependent on the horribly convoluted Visual Basic stack that seems to have a lot of dependencies for some python ML libraries. Docker makes it a lot better to run and I almost always deploy in a docker container because the ML modules I deliver are often interacted with as a black box with a REST API on top.
kart23 6y ago
subtle gendering there.
- deadbunny 6y ago
  I don't see it, but if it reads that way it wasn't my intention.
ninkendo 6y ago
> Can't say I can get behind MS trying to shift maintenance for a Windows only "feature" onto the Linux devs here. Interesting take on the situation. This is effectively a driver they need to get into the kernel (just one that targets a paravirtualization host and not “real” hardware), and Linus has been adamant that the correct way to write a driver in Linux is to upstream it into the kernel. The perspective that upstreaming a driver into the Linux kernel is a burden for Linux kernel developers is one I haven’t heard before, and seems to clash with Linus’s typical stance. Is this something that has some prior examples? Genuinely curious.
- fartcannon 6y ago
  Drivers for use by Linux, not for use by antagonists.

Wowfunhappy 6y ago

Is there a possibility Linux upstream won't accept it?

cdash 6y ago
Sure, 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 ago
That'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 ago
  Yeah 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 ago
If 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.
- kbenson 6y ago
  > 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. I think if that really matters you should be against anything in the kernel to make it work well as a VM under Windows or MacOS or BSD, and in VMware or VirtualBox too. From that point of view, Linux in a VM on another host is taking away from Linux running as a desktop on that host. Linux running as a VM on a VMware cluster is taking away from Linux running on those bare metal servers instead of VMware ESXi. I think the more sane way to look at it is that Linux is an application (and its subcategory is that it is an OS) which is meant to run on various hardware and software platforms, the more the better. This strategy has worked very well over that last couple decades. Does allowing WSL mean that some people that would install Linux on their hardware just run Windows instead and use Linux on top? Probably. Does it mean that people that already ran Windows and have never used Linux get exposed to it for the first time and get familiar with it through a few click on their existing Windows computer? That's also probable. Does it really matter in the end? Probably not.
  - yuribro 6y ago
    > I think if that really matters you should be against anything in the kernel to make it work well as a VM under Windows or MacOS or BSD, and in VMware or VirtualBox too. Why? I would guess that a very large share of linux kernels run under a hypervisor in some data center, in a public cloud or some OpenStack cluster. Won't those mostly be the same features?
    - TeMPOraL 6y ago
      Because WSL doesn't compete with people who would otherwise run a Linux box, it competes with people who would otherwise shove Ubuntu into a VirtualBox and run it on their Windows box in seamless mode. So the idea that it drives people away from Linux proper is nonsense (BTW., WSL is Linux proper), unless you also believe that installing a Linux in a VM on a proprietary system is also driving people away.
Iv 6y ago
Why would it? That's a functionality that can't be used without Microsoft proprietary parts. Unless I missed something, I don't think there is an open source implementation of DirectX somewhere? I doubt the linux devs ever see WLS as a target they have to maintain themselves.
- nitrogen 6y ago
  Wine has an open source implementation of DirectX, FWIW.
  - Iv 6y ago
    Ok, not my field, but isn't it based on OpenGL? Does it count as an implementation or an emulation layer? My understanding is that Microsoft is trying to give WSL a transparent access to the GPU using the regular linux interface and transmitting it to DirectX. Using that with wine would mean adding two emulation layers before reaching the actual driver. I fail to see any use case for that.
    - traverseda 6y ago
      It's based on vulkan, which means that it has low enough level access to the GPU that I think it's fair to call libraries implemented on top of it "native". Most GPU drivers have some kind of translation for directx already, and there's no inherent reason why the open source directx implementation has to perform worse than the GPU implementation of directx. I hear that the open source dx11 implementation actually beats AMD's DX11 implementation in some cases. So yeah, vulkan is neat and opens up a whole lot for the linux world. In the future you'll probably see userspace implementations of opengl on top of vulkan, maybe even CUDA implemented on AMD gpus, although I'm not sure how practical that is. Also a whole lot of exciting GPU sharing tech, accessing GPUs inside of VMs for example. DirectX will come to linux, but it won't be thanks to microsoft. You can thank valve hedging their bets on the microsoft store for that.
bubblethink 6y ago
What would be the big loss other than MS bundling a ppa ? Nvidia drivers and cuda anyway need a ppa. So wsl + nvidia + cuda being a single ppa is anyway not that far off.

lostmsu 6y ago

To be honest I don't quite understand what stopped those developers from running machine learning on their GPUs under Windows itself. Most frameworks work just fine. I've been doing quite a lot of TensorFlow with both Python and .NET. The only time I faced the need for Linux box is trying a demo project from OpenAI, which did not use the features it required Linux for on a single machine anyway.

rezonant 6y ago
I believe the purpose is for devs who are deploying to Linux, their toolchain may not fully work in Windows, but they want to have a similar dev/test env within Windows... pretty much the whole point of Windows Subsystem for Linux (WSL). It's not that the frameworks don't work on Windows, it's the deployment tech, like Docker, Ansible, their build scripts etc etc. Some users may be doing something totally custom on top of the GPU without a framework layer but that is probably very few users. I'd have to guess though that those users would be the type of users that would get MS to go through the effort though...
- lostmsu 6y ago
  Do people actually use Docker and Ansible a lot for ML??? Doing something custom on top of the GPU is also not much different on Windows, than Linux. CUDA is basically the same. OpenCL and Vulkan are available too. I'd like to hear perspective of a person, who actually does ML specifically on Linux for some reason.
  - hetspookjee 6y ago
    Well CUDA is only one thing. Especially in the python environment it's only a matter for time before you run in some wierd dependency issue that is Windows only. For example, getting XGBoost completely up and running on Windows requires you to either build it yourself or download a .dll from a university link. Installing it on Linux is just a proper pip install. Also windows not having a build in C compiler makes you dependent on the horribly convoluted Visual Basic stack that seems to have a lot of dependencies for some python ML libraries. Docker makes it a lot better to run and I almost always deploy in a docker container because the ML modules I deliver are often interacted with as a black box with a REST API on top.

kart23 6y ago

subtle gendering there.

deadbunny 6y ago
I don't see it, but if it reads that way it wasn't my intention.

ninkendo 6y ago

> Can't say I can get behind MS trying to shift maintenance for a Windows only "feature" onto the Linux devs here. Interesting take on the situation. This is effectively a driver they need to get into the kernel (just one that targets a paravirtualization host and not “real” hardware), and Linus has been adamant that the correct way to write a driver in Linux is to upstream it into the kernel. The perspective that upstreaming a driver into the Linux kernel is a burden for Linux kernel developers is one I haven’t heard before, and seems to clash with Linus’s typical stance. Is this something that has some prior examples? Genuinely curious.

fartcannon 6y ago
Drivers for use by Linux, not for use by antagonists.