3 comments

  • markasoftware 18 minutes 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.

    • WanjohiRyan 13 minutes 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
  • mcmatterson 43 minutes 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
    • LiamPowell 0 minutes 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.
    • Borealid 33 minutes 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.

      • WanjohiRyan 8 minutes 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

    • serf 19 minutes 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.
    • WanjohiRyan 40 minutes 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.
      • mcmatterson 37 minutes 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.

        • WanjohiRyan 24 minutes 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

  • majorchord 18 minutes ago
    Can this be used with a Windows guest?
    • WanjohiRyan 13 minutes ago
      No not yet, but that is in the roadmap.