Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

71% Positive

Analyzed from 388 words in the discussion.

Trending Topics

#virtio#nvproxy#https#gpu#project#native#github#com#different#gvisor

Discussion (12 Comments)Read Original on HackerNews

markasoftware29 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.

WanjohiRyan24 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
mcmattersonabout 1 hour 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
LiamPowell11 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.
Borealid44 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.

WanjohiRyan19 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

serf30 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.
WanjohiRyanabout 1 hour 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.
mcmattersonabout 1 hour 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.

WanjohiRyan35 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

majorchord29 minutes ago
Can this be used with a Windows guest?
WanjohiRyan24 minutes ago
No not yet, but that is in the roadmap.