| ▲ | Virtio-nvgpu: Near-native Nvidia GPU access inside a KVM guest(github.com) |
| 49 points by WanjohiRyan 5 hours ago | 20 comments |
| |
|
| ▲ | Datagenerator 2 minutes ago | parent | next [-] |
| Does it work under OpenStack? |
|
| ▲ | orphereus 19 minutes ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | defer 13 minutes ago | parent [-] | | README mentions it supports up to 4 guests at a time sharing the GPU. |
|
|
| ▲ | mcmatterson 3 hours ago | parent | prev | next [-] |
| 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 |
| |
| ▲ | Borealid 3 hours ago | parent | next [-] | | 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 3 hours ago | parent [-] | | 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 | | |
| |
| ▲ | LiamPowell 3 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | vlovich123 2 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | verall 33 minutes ago | parent [-] | | I see everyone saying this but I've been using 6-astra lately and afaict it's not much better |
| |
| ▲ | WanjohiRyan 3 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | jchw 2 hours ago | parent | next [-] | | 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. | |
| ▲ | mcmatterson 3 hours ago | parent | prev [-] | | 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 3 hours ago | parent [-] | | 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 |
|
| |
| ▲ | serf 3 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | markasoftware 3 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent [-] | | 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 |
|
|
| ▲ | hacker_homie 2 hours ago | parent | prev | next [-] |
| What are the isolation implications? |
|
| ▲ | majorchord 3 hours ago | parent | prev [-] |
| Can this be used with a Windows guest? |
| |