Live data from Hacker News

VirGL – A virtual 3D GPU for use inside QEMU virtual machines

docs.mesa3d.org

31–40 of 84 posts

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#31
VirGL is a poor solution to the pressing problem of virtualized graphics. It only really exists because the hardware makers AMD/Intel/Nvidia in their infinite greed refuse to support VFIO on all GPU's like how IOMMU is supported on nearly all CPU's.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#32

VirGL is definitely an interesting project, but all one has to do to get GPU passthrough working (from a Linux QEMU host to any guest OS) is: 1.) research a cheap, secondary GPU that is natively supported by the guest OS, 2.) plug such a secondary GPU into a PCIe slot on the host and hook it up to the primary monitor with a secondary cable (D-Sub vs. DVI, etc.), 3.) setup Linux to ignore the secondary GPU at boot and…

> The whole process takes perhaps one or two hours and as works flawlessly, with no stability issues. Good joke, that really made me laugh :) I tried this on my ASRock X370 Taichi a while back. Turns out that there is a bug in older bios versions and the whole thing just freezes when starting the QEMU VM. Then there is an intermediate bios version with which I actually managed to get it working. Unforunately I later…

> Good joke, that really made me laugh :)

I've been forwarding an AMD GPU to both Windows and macOS for literally years across multiple Asus motherboards and, except for the specific problem of host sleep/wake, had no problems whatsoever, even considering I work under GPU-passthrough VMs whole-day, every-day. Perhaps try a recent Asus motherboard?

> have to dual-boot QEMU VMs or disable the passthrough

Yes, you would have to buy as many cheap, secondary GPUs as the number of virtual machines that you want to run in parallel.

> I really want proper GPU virtualisation...

Sure, I don't blame you - my point was that the only truly usable GPU virtualization solution available today is GPU passthrough and that GPU passthrough is much easier to setup than it is commonly perceived.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#33

VirGL is a poor solution to the pressing problem of virtualized graphics. It only really exists because the hardware makers AMD/Intel/Nvidia in their infinite greed refuse to support VFIO on all GPU's like how IOMMU is supported on nearly all CPU's.

Correct me if I am wrong on this, but to me, it would seem that something like VirGL would still serve a purpose with wider spreader full SR-IOV support on consumer GPUs, as VirGL could find application in many scenarios where a GPU vendor's drivers are not compatible with the guest.

Saying that, I do agree that vendors should enable support in customer GPUs and feel that their focus on protecting server sales is going to turn out misguided in the long term. Intel especially disappointed in this area, as they in the past did allow such functionality on their GPUs, but have recently removed that.

AMDs mainstream CPUs supporting server features such as ECC also have proven that such restrictions aren't necessary, and allowing this type of capability on mainstream platforms in no way harms enterprise sales.

That being said, any effort focused on GPU virtualization or drivers impresses me immensly and I very much appreciate the work done on VirGL.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#35
post #33

VirGL is a poor solution to the pressing problem of virtualized graphics. It only really exists because the hardware makers AMD/Intel/Nvidia in their infinite greed refuse to support VFIO on all GPU's like how IOMMU is supported on nearly all CPU's.

Correct me if I am wrong on this, but to me, it would seem that something like VirGL would still serve a purpose with wider spreader full SR-IOV support on consumer GPUs, as VirGL could find application in many scenarios where a GPU vendor's drivers are not compatible with the guest. Saying that, I do agree that vendors should enable support in customer GPUs and feel that their focus on protecting server sales is goi…

>Correct me if I am wrong on this, but to me, it would seem that something like VirGL would still serve a purpose with wider spreader full SR-IOV support on consumer GPUs, as VirGL could find application in many scenarios where a GPU vendor's drivers are not compatible with the guest.

Pretty much every guest OS (windows, Linux, BSD) has drivers that would work with a native PCIe VF GPU device. MacOS still has AMD drivers but only up to RDNA 2. I can't think of any guest that would support a GL device but not have a native driver.

>Saying that, I do agree that vendors should enable support in customer GPUs and feel that their focus on protecting server sales is going to turn out misguided in the long term. Intel especially disappointed in this area, as they in the past did allow such functionality on their GPUs, but have recently removed that.

Intel supports SRIOV/SIOV on consumer CPU iGPU's (Xe, 11th, 12th, and 13th gen) but not dGPU's (A770, A750..) which is very frustrating. Indeed 'enterprise features' such as ECC or IOMMU on consumer chips have not affected server sales.

>That being said, any effort focused on GPU virtualization or drivers impresses me immensly and I very much appreciate the work done on VirGL.

agreed

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#36

Earlier quoted context omitted.

> The whole process takes perhaps one or two hours and as works flawlessly, with no stability issues. Good joke, that really made me laugh :) I tried this on my ASRock X370 Taichi a while back. Turns out that there is a bug in older bios versions and the whole thing just freezes when starting the QEMU VM. Then there is an intermediate bios version with which I actually managed to get it working. Unforunately I later…

> Good joke, that really made me laugh :) I've been forwarding an AMD GPU to both Windows and macOS for literally years across multiple Asus motherboards and, except for the specific problem of host sleep/wake, had no problems whatsoever, even considering I work under GPU-passthrough VMs whole-day, every-day. Perhaps try a recent Asus motherboard? > have to dual-boot QEMU VMs or disable the passthrough Yes, you would…

> Perhaps try a recent Asus motherboard?

I also have an AM4 ASUS board (is that recent enough?) and earlier this year, ASUS decided to completely remove any mention of this board from their site, as if it never existed. So no bios updates for me I guess? No idea if it is up to date or not or if my CPU is even supported...

> Yes, you would have to buy as many cheap, secondary GPUs as the number of virtual machines that you want to run in parallel.

Except that cheap GPUs are... cheap and not very powerful, so depending on what I want to do I would have to buy a bunch of expensive and powerful GPUs (or go back to rebooting VMs to switch). And there are only so many PCIe slots on my board (2x8 and 1x4, the latter of which is already in use by a non-GPU card). Running them in an x1 slot also doesn't sound like a great idea.

I have tried to run it but gave up in the end after breaking bios updates and not wanting to spend even more money on another fast GPU.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#37

Earlier quoted context omitted.

> The whole process takes perhaps one or two hours and as works flawlessly, with no stability issues. Good joke, that really made me laugh :) I tried this on my ASRock X370 Taichi a while back. Turns out that there is a bug in older bios versions and the whole thing just freezes when starting the QEMU VM. Then there is an intermediate bios version with which I actually managed to get it working. Unforunately I later…

> Good joke, that really made me laugh :) I've been forwarding an AMD GPU to both Windows and macOS for literally years across multiple Asus motherboards and, except for the specific problem of host sleep/wake, had no problems whatsoever, even considering I work under GPU-passthrough VMs whole-day, every-day. Perhaps try a recent Asus motherboard? > have to dual-boot QEMU VMs or disable the passthrough Yes, you would…

> Perhaps try a recent Asus motherboard

And if I don't want to or can't afford to buy new hardware?

> Sure, I don't blame you - my point was that the only truly usable GPU virtualization solution available today is GPU passthrough and that GPU passthrough is much easier to setup than it is commonly perceived.

Okay, but for the poster you're replying to it is not available on their hardware.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#38

Earlier quoted context omitted.

> Good joke, that really made me laugh :) I've been forwarding an AMD GPU to both Windows and macOS for literally years across multiple Asus motherboards and, except for the specific problem of host sleep/wake, had no problems whatsoever, even considering I work under GPU-passthrough VMs whole-day, every-day. Perhaps try a recent Asus motherboard? > have to dual-boot QEMU VMs or disable the passthrough Yes, you would…

> Perhaps try a recent Asus motherboard? I also have an AM4 ASUS board (is that recent enough?) and earlier this year, ASUS decided to completely remove any mention of this board from their site, as if it never existed. So no bios updates for me I guess? No idea if it is up to date or not or if my CPU is even supported... > Yes, you would have to buy as many cheap, secondary GPUs as the number of virtual machines tha…

> I (...) have an AM4 ASUS board

No, I never tried GPU passthrough with an AMD CPU, Intel only.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#39
There's also virgl_test_server which runs the virgl protocol over a socket.

This can be used for OpenGL inside containers, by bind mount-ing the socket into the container (/tmp/.virgl_test).

Also useful for debugging with rr, even with the nvidia driver you use OpenGL over virgl with the environment vars __GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=virpipe

Post reply on HN