Live data from Hacker News

Show HN: vGPU and SR-IOV on consumer GPUs

arccompute.com

31–40 of 82 posts

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#32

This 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 yaml configuration layer so from our perspective it's already possible to use but unfortunately until the nv merged drivers work with Ampere we won't be able to do a lot on our end.. Right now I think the vGPU_Unlock guys are working on the 3090 and we'll be sure to support it once it's ready. I'll also try to remember to post about it on GitHub once I've tested it out for myself and confirmed our software works with it.

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

#33

I'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…

> sdl/gtk display is flakey

How is it compared to spice/qxl - does it have some advantages?

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#35

This 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…

Super thrilled to hear you guys working on the 3090! I'll be keeping an eye out for any progress

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#37
Just to clarify because I've failed at doing pretty much the setup that you are describing with my 1080Ti. Does this still require the vgpu_unlock changes for Nvidia cards or is this something that bypasses the need for it entirely?

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#38
post #6

This 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…

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

Re: Show HN: vGPU and SR-IOV on consumer GPUs

#39
That's very impressive!

You 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

#40
post #38

Earlier 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

For replacing RemoteFX vGPU, what you might want is https://forum.level1techs.com/t/2-gamers-1-gpu-with-hyper-v-...

(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).

Post reply on HN