72 pointsby WanjohiRyan7 hours ago8 comments
  • mjg59an hour ago
    Hrm, something of a lack of discussion about what level of access the card has to the host in the absence of IOMMU-restricted passthrough.
    • orphereusan hour ago
      I am very sceptical about this. I have some experience in GPU virtualization and passthrough with Nvidia GPUs and they are really not designed to be able to share them with multiple guests/host without Nvidia's blessing (licenced drivers).
      • WanjohiRyanan hour ago
        Yes they are not... we run the Nvidia drivers unmodified. Only thing we have done is make the guest driver think it's running on the host, talking to the host's GPU kernel.

        It works really well with a ~2% performance penalty. Nvproxy by google/gvisor has been doing this for years.

        You should try running it yourself and see how it goes :D

        • orphereus39 minutes ago
          So you can share the GPU between multiple VMs? I can have 4 VMs simultaneously do work on the GPU?

          And each one would have its own Nvidia driver? How do they not interfere with each other? I mean I am by no means an expert in GPU architecture or anything similar, but I thought the problems with sharing a GPU come from the differences between GPU vs CPU architecture. On the other hand, multiple processes on a host can run on the same GPU, but that is all using the same kernel. I am just very confused.

          • madushan100017 minutes ago
            This has been a thing for AMD, Intel, and Qualcomm GPUs for a few years now. Search for "DRM native context". The only difference here is that you had to use mesa drivers before and now someone made it work with the Nvidia drivers.
        • rwmj20 minutes ago
          How is this different (in effect, not technically) from just using PCI passthrough, apart from being less safe and less tested?
          • WanjohiRyan8 minutes ago
            Fair point, we still have a long way to go in terms of security AND being suitable for everyday use.

            However, nvgpu is meant to be used in PCI passthrough in scenarios where you would want to run and share your GPU across multiple KVM guests, or you don't want to detach the GPU from the host, and plug it into the VM you are running... you know, that little dance you do everytime you want to game inside a VM.

        • mjg59an hour ago
          Does "how it goes" include the guest being able to DMA over the host kernel?
  • mcmatterson5 hours ago
    Amazing project! But man, that README is just a textbook example of LLM word salad. It's wild how these tools are so incredibly capable at many things, but their writing sticks out like a sore thumb
    • Borealid5 hours ago
      The percentage-overhead comparison is pretty choice nonsense. It has only percentages to try and "explain" that overheads don't matter if the system is slow anyhow.

      A fair comparison would be this project vs virtio.

      • WanjohiRyan5 hours ago
        Virtio? what virtio? virtio native drm native context, is that what you mean? We actually use it in nesbox[1] for AMD/Intel cards.

        Venus is the only one we could directly compare to, as it is the only one that supports Nvidia GPUs. vDRM works only on AMD/Intel GPUs and has a similar performance (~98% baremetal performance) to virtio-nvgpu.

        [1] https://github.com/nestrilabs/nesbox

    • LiamPowell5 hours ago
      When the lines in the ASCII charts don't even line up my immediate assumption is that the author didn't even bother to glance at it.
    • vlovich1234 hours ago
      Claude is much worse for having a distinctive style you can spot from a mile away. I’ve found GPT-6 to not suffer from this or it’s insanely verbose markdown salad.
      • verall3 hours ago
        I see everyone saying this but I've been using 6-astra lately and afaict it's not much better
    • WanjohiRyan5 hours ago
      My bad, i am not a native English speaker... I did my best to try and brush it up. Terribly sorry if it did not match your flow.
      • jchw4 hours ago
        LLMs are pretty good at translation, they're just pretty awful at generating natural-sounding English prose from scratch. In my opinion, probably the best solution is to simply write the README in your native tongue and use an LLM to translate it.
        • junonan hour ago
          This! Claude word salad is worse than maybe subpar translations, with which I'm sure PRs can help.
      • mcmatterson5 hours ago
        All good friend! I'm as guilty as anyone. It's a super cool project though.

        Now that I have you on the hook, is there any benefit to this over virtio for a single KVM passthrough situation? I previously ran a proxmox based gaming PC setup (docs here: https://github.com/mtrudel/rabble/tree/4d9329f3dd0fb09123a8f...), and was lucky enough that the GPU passthrough part of that build 'just worked'. I'd started down a path of trying to share the GPU between VMs based on a naive 'one VM owns it at a time' setup, but never really got it off the ground.

        • WanjohiRyan5 hours ago
          The benefit is that you do not have a limit to how many VMs you can run at the same time. However, virtio-nvgpu has no Windows support as of yet, please check back in a while :)

          You should check out Nestri [1], another project we are working on, that helps you do exactly that. It helps run multiple gaming sessions for you and your friends on the same GPU, without anyone meddling in the other person's session. Everyone gets to stream their game to whatever desktop or device they want. It is still a work-in-progress though.

          [1] https://github.com/nestrilabs/nestri

    • serf5 hours ago
      it's not just literary authorship, it's pretty easy to spot LLM driven programming paradigms too, especially if you look at the test suites of a given package.
  • orphereus2 hours ago
    Why not use normal GPU passthrough? I don't see how you can use this to share a GPU between multiple VMs, so what is the benefit of using this software over normal GPU passthrough with vfio-pci drivers?
    • Tajnymag2 hours ago
      With normal passthrough, your host loses access to the gpu, no? So you need to have two gpus, one for the host and one for the guest. Correct me, if I am wrong, but this should make the host fully operational on a single gpu and still let vm guests have headless access to the host gpu.
      • orphereusan hour ago
        Is it really that simple to split an Nvidia GPU between multiple users like that? I thought that you have to have specific drivers which support that.
        • gmerc16 minutes ago
          that's paid
    • defer2 hours ago
      README mentions it supports up to 4 guests at a time sharing the GPU.
      • orphereusan hour ago
        I am wondering how they managed to achieve that without using Nvidia vGPU drivers.
  • markasoftware5 hours ago
    How is this different than gVisor's nvproxy? https://gvisor.dev/docs/user_guide/gpu/#compatibility

    Edit: nvproxy is mentioned as the "direct inspiration" in the readme without mention of how this is different or why it doesn't use nvproxy as a backend.

    • WanjohiRyan5 hours ago
      We borrowed a lot of the architectural design from nvproxy, then built it to support graphical workloads. Plus it is reusable in such a way you can hot plug it into any microVM, cloud-hypervisor, maybe even Firecracker
      • 3 hours ago
        undefined
  • vsviridov21 minutes ago
    Can this be used with proxmox?
  • hacker_homie4 hours ago
    What are the isolation implications?
  • Datagenerator2 hours ago
    Does it work under OpenStack?
  • majorchord5 hours ago
    Can this be used with a Windows guest?
    • WanjohiRyan5 hours ago
      No not yet, but that is in the roadmap.