3 ms·

It had gotten to the point where you can do machine learning and other CUDA applications, and that brings a lot more money than graphics. WSL is definitely pul

It had gotten to the point where you can do machine learning and other CUDA applications, and that brings a lot more money than graphics. WSL is definitely pulling an Embrace Extend Extinguish. I am not saying the new Microsoft is the same as Ballmer's, but still.

monocasa 6y ago
Full graphics is on the roadmap, basic compute was just an MVP. Linus has said that he doesn't want discussions without code for the reasons I've stated. All the complaints I've heard about how WSL didn't do the right thing make it sound like there is no right way, despite passthrough graphics drivers for otherwise totally proprietary stacks on hypervisor stacks from companies with blatant GPL violations ending up mainlined with praise (cough VMWare). And despite the fact that the only way that's been proven to virtualize graphics cards without 2stage MMUs is to replicate the host's ioctl layer into the guest. There's a reason why Virgl isn't used by anyone serious about perf, it's the fundamentally wrong architecture.
- bonzini 6y ago
  CUDA may be an MVP, but it's a damn useful and lucrative MVP. Also, VFIO mdev can be used to virtualize graphics cards to virtual machines, both nVidia and Intel. Note this is not device assignment (that's "plain" VFIO); it's the host driver exposing a partly pass-through, partly emulated device that virtualizes the host device. mdev's design was initially a Red Hat-nVidia collaboration with input from Intel (I had a small role from the Red Hat side, mostly coming up with the name :-)) and implemented by nVidia, and is used in production with both Windows and Linux guests.
  - monocasa 6y ago
    It's not full VFIO, but it still takes hardware support. It's not really a comparable solution.
    - bonzini 6y ago
      Not necessarily. Nvidia doesn't have hardware support, rather the guest driver communicates changes to the page tables to the host driver in such a way that the host can establish shadow page tables that merge the guest and host translations.
      - monocasa 6y ago
        That's not a great example though, because mdev on Nvidia is proprietary kernel module->proprietary guest kernel module->proprietary user driver. And in that case too, the ioctl layer is almost entirely maintained across the boundaries like the scheme I'm saying. You need to do that or you almost certainly get a weird impedance mismatch between guest and host that destroys perf.
        bonzini 6y ago
        Even if nVidia's driver has a more lightweight abstraction compared to Intel's, and puts more stuff in userspace, that is not particularly relevant in my opinion: mdev only sits between host and guest driver and by design the host driver only emulates the bare minimum and multiplexes hardware resources instead. What happens in the guest between the driver and userspace does not matter to mdev.
        monocasa 6y ago
        It is relevant, because NVidia's binary driver looks like WDDM on every platform. And Intel needs something like this either way because their hardware arch is different, and their GPU is heavily integrated with the main IOMMU.

monocasa 6y ago

Full graphics is on the roadmap, basic compute was just an MVP. Linus has said that he doesn't want discussions without code for the reasons I've stated. All the complaints I've heard about how WSL didn't do the right thing make it sound like there is no right way, despite passthrough graphics drivers for otherwise totally proprietary stacks on hypervisor stacks from companies with blatant GPL violations ending up mainlined with praise (cough VMWare). And despite the fact that the only way that's been proven to virtualize graphics cards without 2stage MMUs is to replicate the host's ioctl layer into the guest. There's a reason why Virgl isn't used by anyone serious about perf, it's the fundamentally wrong architecture.

bonzini 6y ago
CUDA may be an MVP, but it's a damn useful and lucrative MVP. Also, VFIO mdev can be used to virtualize graphics cards to virtual machines, both nVidia and Intel. Note this is not device assignment (that's "plain" VFIO); it's the host driver exposing a partly pass-through, partly emulated device that virtualizes the host device. mdev's design was initially a Red Hat-nVidia collaboration with input from Intel (I had a small role from the Red Hat side, mostly coming up with the name :-)) and implemented by nVidia, and is used in production with both Windows and Linux guests.
- monocasa 6y ago
  It's not full VFIO, but it still takes hardware support. It's not really a comparable solution.
  - bonzini 6y ago
    Not necessarily. Nvidia doesn't have hardware support, rather the guest driver communicates changes to the page tables to the host driver in such a way that the host can establish shadow page tables that merge the guest and host translations.
    - monocasa 6y ago
      That's not a great example though, because mdev on Nvidia is proprietary kernel module->proprietary guest kernel module->proprietary user driver. And in that case too, the ioctl layer is almost entirely maintained across the boundaries like the scheme I'm saying. You need to do that or you almost certainly get a weird impedance mismatch between guest and host that destroys perf.
      - bonzini 6y ago
        Even if nVidia's driver has a more lightweight abstraction compared to Intel's, and puts more stuff in userspace, that is not particularly relevant in my opinion: mdev only sits between host and guest driver and by design the host driver only emulates the bare minimum and multiplexes hardware resources instead. What happens in the guest between the driver and userspace does not matter to mdev.
        monocasa 6y ago
        It is relevant, because NVidia's binary driver looks like WDDM on every platform. And Intel needs something like this either way because their hardware arch is different, and their GPU is heavily integrated with the main IOMMU.