Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: vGPU and SR-IOV on consumer GPUs

arccompute.com

Post reply on HN
Print view View original

41–50 of 82 posts

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

#41

Post by kipchak »

my123 wrote: post #40
kipchak wrote: post #38

Earlier quoted context omitted.

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

Interesting! News to me, the Microsoft documentation I was looking at didn't make any mention of GPU-P but that seems like a perfect fit. Was looking at a old Grid K2 to avoid Nvidia licensing and direct pass through for high use VMs but as we're full Microsoft (for better or worse) their solution probably makes more sense.

edit - apparently while this works on Server 2019 direct pass through is the only officially "supported" option. I wonder if this is a stepping on partners' toes sort of situation?

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

#42

Post by my123 »

kipchak wrote: post #41
my123 wrote: post #40

Earlier quoted context omitted.

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

Interesting! News to me, the Microsoft documentation I was looking at didn't make any mention of GPU-P but that seems like a perfect fit. Was looking at a old Grid K2 to avoid Nvidia licensing and direct pass through for high use VMs but as we're full Microsoft (for better or worse) their solution probably makes more sense. edit - apparently while this works on Server 2019 direct pass through is the only officially "…

GPU-P is also the GPU acceleration infrastructure used for GPU acceleration in WSL2 and for Windows Sandbox too.

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

#44

Post by uberduper »

posix_me_less wrote: post #33
uberduper wrote: post #11

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?

In my case with 4k monitors and virgl, it's substantially faster and a desktop env feels native. Spice feels quite laggy to me.

The downside is that the sdl or gtk interface is coupled to the running vm and if they crash, the vm goes too. And in my experience, they crash a lot. I've been unable to get a two monitor setup working with either the sdl or gtk display but it works fine via spice.

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

#45

Post by ArcVRArthur »

kipchak wrote: post #38
ArcVRArthur wrote: post #21

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

vGPU_Unlock's Merged driver is an optional package you can include but if you don't want to use it there's no explicit dependance. We actually enable these features using a vendor neutral API called VFIO-Mdev:

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/drive...

Here's a few examples of YAML for use with different GPU vendors:

Intel: https://github.com/Arc-Compute/libvf.io/blob/master/example/...

Nvidia: https://github.com/Arc-Compute/libvf.io/blob/master/example/...

AMD: https://github.com/Arc-Compute/libvf.io/blob/master/example/...

The odd one out is AMD that uses a different API due to the fact that the vendor has largely ignored standard open source interfaces in the kernel. We're still supporting that API but unfortunately there are very few AMD cards that work due to the fact that they refuse to release open source code to support their newer cards and they have locked out these features at the firmware level on consumer cards. Fortunately Nvidia and Intel GPUs are very well suited to this functionality and we've got support for most recent consumer cards from both!

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

#46

Post by ArcVRArthur »

my123 wrote: post #40
kipchak wrote: post #38

Earlier quoted context omitted.

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

I think Hyper-V is GPU-P is great! I think Microsoft's hypervisor team is one of the most talented in the world, and honestly I think I could learn a lot from them.

One of the benefits to using our approach instead of Microsoft's is that our tools are free open source software and (my biased opinion) I think we have an easier user setup. :)

Some day I would love to read Hyper-V's GPU-P code as I think they did a rather good job overall.

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

#47

Post by ArcVRArthur »

kipchak wrote: post #41
my123 wrote: post #40

Earlier quoted context omitted.

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

Interesting! News to me, the Microsoft documentation I was looking at didn't make any mention of GPU-P but that seems like a perfect fit. Was looking at a old Grid K2 to avoid Nvidia licensing and direct pass through for high use VMs but as we're full Microsoft (for better or worse) their solution probably makes more sense. edit - apparently while this works on Server 2019 direct pass through is the only officially "…

I'm not entirely sure on how wide the vendor support is but I wouldn't be entirely surprised if they were upsetting some folks with it. Happily we're just a little team right now making stuff that's useful for ourselves so we don't have all the same pressures big companies have. I hope if we ever grow we'll act in the same spirit (I'll try my best to see that we do anyway).

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

#48

Post by ArcVRArthur »

belval wrote: post #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?

My main development rig actually uses a 1080Ti!

The normal vGPU_Unlock steps aren't a part of the user setup process, rather the optional merged driver package is built with a C version of the code that's been prepackaged. If you decide to use the vGPU_Unlock merged driver option during setup you won't have to do the (somewhat intense) process of vGPU_Unlock setup, you'll just skip straight to the end result. :)

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

#49

Post by ArcVRArthur »

ArtWomb wrote: post #36

Whoa! Multi GPU is so hard. This could be the start of something. Looks like it makes use of nvidia's capture api?

We've been working on this for awhile and ya, I hope it is the start of something! If you want to read the logical origin point of where I started thinking about this project check this out:

https://arccompute.com/blog/why-computers-suck-and-how-openb...

https://news.ycombinator.com/item?id=21776370

We're not using Nvidia's APIs in our code! libvf.io is entirely based on cross-vendor, standard APIs. :D

The one that is a bit weird is AMD who is fairly far behind Nvidia and Intel but I think if they want to modernize support they can definitely do it. My hope is that consumers will start asking for this capability more (especially with Intel's ARC GPUs enabling GVT-g at every price point) and AMD will update their stuff to reflect that demand.

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

#50

Post by ArcVRArthur »

csdvrx wrote: post #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".

That's actually a great idea!

Is there any documentation you would suggest I read to get started understanding NVMe namespaces?

We're also very open to feature additions/pull requests at our repo: https://libvf.io/ I'm very new to this whole thing of building an open source community but I hope if people find value in some of what they built that they might consider helping us with our code.

If you have any suggestions on how we could improve and build a good open source community I'd love to hear them!

Post reply on HN