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

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

docs.mesa3d.org

Post reply on HN
Print view View original

41–50 of 84 posts

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

#41

Post by diffeomorphism »

arghwhat wrote: post #27
denkmoon wrote: post #22

Earlier quoted context omitted.

Except that requires IOMMU which is not always available nor is it always reliable on consumer motherboards.

IOMMU is a integrated CPU feature, so consumer motherboards do not affect reliability - they just make the setting available. IOMMU is also required for various modern security features, and M$ requires it for certification nowadays to protect against DMA vulnerabilities (heard of thunderbolt?).

No.

Just because your CPU supports IOMMU, that does not mean GPU passthrough is going to work properly or that groups are setup properly or....

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

#42

Post by h2odragon »

amelius wrote: post #40

I'm wondering if this approach could mean we'd one day be able to have CUDA running on non-Nvidia GPUs.

> Out of scope: Passing through GPUs or subsets of GPU capabilities.

Perhaps, but that should probably be a different project. They want a different focus here.

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

#43

Post by codedokode »

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

Isn't it dangerous to give a guest direct access to a GPU?

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

#44

Post by codedokode »

gary17the wrote: post #21

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…

> plug such a secondary GPU into a PCIe slot on the host

Where can I find an unused PCIe slot on my laptop?

Also it is not very rational to buy 2 GPUs and use only one at a time.

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

#45

Post by rzzzt »

kevingadd wrote: post #15
w-ll wrote: post #10

Its virtual... but passthrough, I would like to see something thats virtual but runs on pure cpu x86 or arm, do not care how slow.

On Windows, there's a pure software implementation of Direct3D 11 called WARP https://learn.microsoft.com/en-us/windows/win32/direct3darti...

There was a third-party one around DirectX 9 with a shiny car demo. It later became the foundations of ANGLE, I think (present day SwiftShader implements the Vulkan API): https://developer.chrome.com/blog/swiftshader-brings-softwar...

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

#46

Post by [deleted] »

codedokode wrote: post #43
throwaway698585 wrote: post #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.

Isn't it dangerous to give a guest direct access to a GPU?

[deleted]

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

#48

Post by ArtWomb »

throwaway698585 wrote: post #35
Topfi wrote: post #33

Earlier quoted context omitted.

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

GPU Virtualization: life's toughest challenge ;)

GVT-g high-level design

https://projectacrn.github.io/1.6/developer-guides/hld/hld-A...

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

#49

Post by chris37879 »

Topfi wrote: post #33
throwaway698585 wrote: post #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.

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…

Yeah, I would love to have api layer pass through as well as pcie layer pass through. API pass through would work well for things like containers or sandbox environments.

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

#50

Post by gumballindie »

codedokode wrote: post #44
gary17the wrote: post #21

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…

> plug such a secondary GPU into a PCIe slot on the host Where can I find an unused PCIe slot on my laptop? Also it is not very rational to buy 2 GPUs and use only one at a time.

All gaming laptops come with a secondary gpu. What i do on mine is a disable the dedicated gpu, enable passthrough, and voila - shitty windows can run virtualised with a dedicated gpu. Takes 5-10 mins to do so. Also if your laptop supports thunderbolt or usb4 then all you need is an egpu. But thats the more pricey solution.

Having said that virgl is pretty darn sweet!

Post reply on HN