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

21–30 of 82 posts

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

#21

Post by ArcVRArthur »

gh123man wrote: 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.

Right now we've got support in our install script for Ubuntu 20.04 hosts and arbitrary guest operating systems (Windows guests work best so far) but if people on GitHub are posting issues asking for support for other systems I'll try my best to get to those.

I'm going to try to add official support for Arch, PopOS, and Fedora as I know some people who I think would use it on those systems and a few others.

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

#22

Post by awesnvadsome »

This seems awesome! I have a passthrough setup with a very old card and a much newer one for games in a windows vm, it'll be nice to look into getting this set up and I can reduce the power draw on my system which was causing some problems...

Is this something that could work with/be integrated with libvirt for easy configuration? Itd be neat to set it up with my current install, although not at all a real problem.

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

#23

Post by rektide »

Really hoping AMD eventually does the right thing here. Not that it particularly matters seeing as how decent AMD video cards have been unpurchaseable for 18 months now.

Consumers should have the ability to use their hardware well too. Selling the same thing at 2X the price differentiating only on virtualization capabilities is not a moral path.

> We remain hopeful that AMD will recognize forthcoming changes in GPU virtualization with the creation of open standards such as Auxiliary Domains (AUX Domains), Mdev (VFIO-Mdev developed by Nvidia, RedHat, and Intel), and Alternative Routing-ID Interpretation (ARI) especially in light of Intel's market entrance with their ARC line of GPUs supporting Intel Graphics Virtualization Technology (GVT-g).

Really cool to hear there are a bunch of vGPU-related efforts underway! That's so great.

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

#24

Post by ArcVRArthur »

awesnvadsome wrote: post #22

This seems awesome! I have a passthrough setup with a very old card and a much newer one for games in a windows vm, it'll be nice to look into getting this set up and I can reduce the power draw on my system which was causing some problems... Is this something that could work with/be integrated with libvirt for easy configuration? Itd be neat to set it up with my current install, although not at all a real problem.

We actually are a replacement for Libvirt that tries to simplify a few things. Take a look at LibVF.IO's user API. I tried to make it a bit more human friendly, like Docker: https://github.com/Arc-Compute/libvf.io/blob/master/example/...

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

#25

Post by awesnvadsome »

ArcVRArthur wrote: post #24
awesnvadsome wrote: post #22

This seems awesome! I have a passthrough setup with a very old card and a much newer one for games in a windows vm, it'll be nice to look into getting this set up and I can reduce the power draw on my system which was causing some problems... Is this something that could work with/be integrated with libvirt for easy configuration? Itd be neat to set it up with my current install, although not at all a real problem.

We actually are a replacement for Libvirt that tries to simplify a few things. Take a look at LibVF.IO's user API. I tried to make it a bit more human friendly, like Docker: https://github.com/Arc-Compute/libvf.io/blob/master/example/...

Neat! Certainly more readable than the massive xml file! Thanks for the hard work!

E: The code generating the qemu commands is also quite readable, so I think migrating my install will be quite doable + If needs be i can add args manually.

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

#26

Post by ArcVRArthur »

DiabloD3 wrote: post #20

I tried doing this years ago, and never quite go it to work. Some of the software involved in that article simply didn't exist yet, and GPUs weren't shipping with SR-IOV support yet (instead, I did Intel iGPU for Linux fbcon, real AMD GPU fed directly to the Windows VM with PCI-E Passthrough). In the end, I bailed on that dream and moved the Linux install to its own smaller machine, and ran Windows bare on the big ma…

I got into writing this actually because graphics sharing was such a bad experience that I would usually run a Windows host and then Linux guests in something like VirtualBox or VMWare Workstation. I always wanted a host with fault tolerant guests but GPU sharing features seemed to be locked to "enterprise GPUs" and it wouldn't work on my consumer GPU. This solves some of those problems I was having and lets me run Linux on my host with a full performance Windows guest (at least for me it does).

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

#27

Post by xt00 »

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…

Yea what / where is arcd? is that a closed source portion of this stack that this depends upon? not super clear what is really open source about this stuff -- this looks like a pile of scripts to run arcd?

edit: ok thanks so its qemu-system-x86_64

Have you guys tried to run something like android in the vm on an arm host? or what are the limitations there?

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

#28

Post by ArcVRArthur »

xt00 wrote: post #27
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…

Yea what / where is arcd? is that a closed source portion of this stack that this depends upon? not super clear what is really open source about this stuff -- this looks like a pile of scripts to run arcd? edit: ok thanks so its qemu-system-x86_64 Have you guys tried to run something like android in the vm on an arm host? or what are the limitations there?

All the source code for arcd is here: https://github.com/Arc-Compute/libvf.io/tree/master/src

:)

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

#29

Post by ArcVRArthur »

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…

arcd is actually the part of the program that you call in your shell to use our library's functions. Arc Compute is the name of our company so arcd seemed like a reasonable name. We also considered calling it vfd but so far we've settled on arcd.

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

#30

Post by ArcVRArthur »

rektide wrote: post #23

Really hoping AMD eventually does the right thing here. Not that it particularly matters seeing as how decent AMD video cards have been unpurchaseable for 18 months now. Consumers should have the ability to use their hardware well too. Selling the same thing at 2X the price differentiating only on virtualization capabilities is not a moral path. > We remain hopeful that AMD will recognize forthcoming changes in GPU v…

I have to pinch myself from time to time to remind myself I'm not dreaming. I honestly feel like I'm working on the coolest project in the world with some of the smartest people I've ever met. If you know anyone who wants to help us work on open source vGPU stuff please reach out to me at arthur@arccompute.com.

We're hiring!!!

Post reply on HN