Show HN: vGPU and SR-IOV on consumer GPUs
31–40 of 82 posts
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#32This looks really nice. Does this work with Ampere GPUs?
By the way, we're hiring GPU driver engineers and kernel hackers!
Please reach out to me if you know anyone who might be interested. My email is: arthur@arccompute.com
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#33I'm familiar with linux virtualization, gpu passthrough, etc. I've never heard of arcd and they've made no attempt in this doc or on their git to explain what it is or why it exists as, I assume, a replacement (or wrapper?) for qemu. My past experience with looking-glass is that it falls on its face at anything > 1440p@60Hz. I'm interested in vGPU for my linux VMs (spice is slow and sdl/gtk display is flakey) but for…
How is it compared to spice/qxl - does it have some advantages?
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#34Re: Show HN: vGPU and SR-IOV on consumer GPUs
#35This looks really nice. Does this work with Ampere GPUs?
We're supporting Ampere in our own VPS cloud (arccompute.com) but there are some hurtles on getting it working on consumer Ampere gear in the nv merged driver due to changes in the use of SR-IOV APIs - that is to say Nvidia has now enabled SR-IOV whereas before they were doing their entirely different thing to achieve similar functionality. We've got SR-IOV APIs working with our use of mdevType: "sriovdev" in our yam…
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#36Re: Show HN: vGPU and SR-IOV on consumer GPUs
#37Re: Show HN: vGPU and SR-IOV on consumer GPUs
#38This is insanely impressive. Having tried set up GPU passthrough in proxmox a few years ago, it was an absolute disaster. I would love to see this kind of approach more widely supported by other hypervisors! It's a real shame consumer GPUs are arbitrary locked down when the enterprise counterparts (often with the exact same chip) have much better support for virtualization.
Ya the lock out is absolutely arbitrary. There is zero physical difference between the consumer and server chips for these features. I think actually there's a lot of benefit to consumers by having these features enabled! I talk about that a bit here in our Xorg Developer Conference 2021 talk: https://www.youtube.com/watch?v=8pVrTyLqV_I We're going to try to add support for more distributions in the coming days. Righ…
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#39You may want to do the same for NVMe: creating several namespaces is not supported on most consumer drives, while laptops can rarely have more than 1 NVMe (same problem as with the GPUs: a passthrough requires having 2 of them)
Being able to split the NVMe drive not by partition but by namespace would let each OS see a "full drive".
Re: Show HN: vGPU and SR-IOV on consumer GPUs
#40Earlier quoted context omitted.
Ya the lock out is absolutely arbitrary. There is zero physical difference between the consumer and server chips for these features. I think actually there's a lot of benefit to consumers by having these features enabled! I talk about that a bit here in our Xorg Developer Conference 2021 talk: https://www.youtube.com/watch?v=8pVrTyLqV_I We're going to try to add support for more distributions in the coming days. Righ…
Is the process of unlocking these features on Nvidia GPUs similar to something like the vgpu_unlock tool is doing?[1] No affiliation, just came across it trying to find a replacement to the deprecated RemoteFX vGPU and am out of my depth. [1] https://github.com/DualCoder/vgpu_unlock
(which is the direct successor)
The advantage is that it ships inbox in Windows and doesn't need license hacks or anything. It works cross-vendor too.
However, it needs the host OS to be Windows (with Hyper-V being used).