GPU support for 3D graphics in RHEV

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Virtualization (RHEV) 3.2, 3.3, 3.4, and 3.5

Issue

  • What is the road map for supporting multiple host side connections to one or more GPU's to support client VDI connection that are utilizing 3D graphics (Open GL 2.1 - 4.2)?
  • Is it possible to use Aero on my Windows 7 guest in RHEV? When I try to enable Aero, Windows is showing this error:

    Video device can't handle 3D rendering
    
  • Are there any alternates to VDI that would allow thin clients to take advantage of host GPU hardware?

Resolution

At the time of this writing, Red Hat Enterprise Virtualization 3.X does not support GPU acceleration or 3D graphics in a virtual machine.

However, a Request for Feature Enhancement (RFE) has been filed to add 3D acceleration support to kvm virtual machines, which RHEV uses. This RFE is being tracked in a private Red Hat Bug # 991235. For more information or to also request this feature, please open a case with Red Hat Support1.

Work is being done upstream with the Virgil project to create a simple acceleration solution that works well enough for Desktop 3D and OpenGL applications inside the guest. Virgil doesn't require specific licenses or proprietary code and should work with cards from multiple vendors.

Note: This only deals with guest capabilities. Spice client hardware acceleration is handled separately.

Root Cause

In RHEV 3.x, only 2D video devices are supported, however there are plans that will allow 3D devices from the host to be passed to VMs:

  • This will be implemented using VFIO.
  • Currently, VFIO is not stable and only supports a few specific devices in upstream kernels. Support for this is expected in RHEL 7 or later.

Further, when using SPICE, the protocol uses the video device on the connecting client, rather than the device on the VM:

  • SPICE does this by sending processing instructions to the client rather than already rendered images.
  • While SPICE can use 3D client devices, the SPICE protocol itself does not yet support 3D rendering.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

9 Comments

this would seem to really put RedHat's product offering significantly behind the competition (e.g. a competitor's product offering allows us to get near native GPU acceleration for VDI running of graphics intensive applications)... I'd love to be able to make the case for RHEV, instead. :(

There has been a lot of interest in 3D support in RHEV and often it is similar to your comment. I too think it might be valuable, but one of the pieces of information that is often missing is the use-case. In general, 3D is not critical for most office applications which may be the majority of the use-cases for RHEV VDI, but that assumption could be way off the mark.

Having use-cases might help show the value of implementing 3D.
If 3D acceleration was available in RHEV, how would you use it?
Do you have existing 3D applications running on hardware that would be implemented on virtual machine guests?
Are there real-world implementations where another VDI solution was chosen because RHEV does not currently support 3D acceleration?

A LOT of stuff, including the desktop itself, needs GL to do rendering (and that's just on the linux side). I'm not sure what Wayland, which would seem to be the future, is.

So, use cases... even a basic Gnome3 desktop wants accelerated 3D rendering. Web browsers are using accelerated rendering for their webpages. In an office environment, if one wants to even watch a youtube video, 3D, again. There's also Cinnamon or Mate/Compiz, which again, you want good 3D.

Here at Cornell, physical desktops are started to be replaced by thin clients. Because RedHat does not support accelerated 3D video, RHEV was not chosen as the university-wide solution for our Desktop Anywhere offering.

Video editing is a good use case.

If you haven't already, the most direct way to influence this is to open a support case requesting 3D support for VDI in RHEV and providing your justification and use-case(s). As mentioned above, state that another product was selected for desktop clients, in part (or whole), due to the lack of 3D support in RHEV.

As Pete indicated, if you open a case and reference this comment thread, the existing RFE and your business use-case can be added to the discussion. This will be helpful for product management. If you post your case number here, I can take care of it personally.

Hi. Reference case 01458484 .

Thanks, David. I attached your case to the existing RFE. I also provided product management with the use case described in your case notes.

Hi. Was curious what the latest is.

thanks.

Hey David, the best place to ask for updates on this is through the support case. However, since a number of folks have asked, I have updated this kbase to include additional information and I'll reply here as well.

The original feature request here was so that folks could use simple desktop acceleration like "Aero on Windows 7 as it offers a lot of usability improvements over classic view, like window previews on taskbar."

If you look at the work being done upstream, this is where virtio-gpu (Virgil) comes into play. It's a simple acceleration solution that works well enough for 3D/OpenGL applications inside the guest. Virgil doesn't require specific licenses or proprietary code and should work with cards from multiple vendors. Local virgil support (Spice console via virt-manager) should be arriving in an upcoming version of Fedora and eventually in RHEL 7.

Eventually, there will be at least 2 solutions for 3D acceleration in guests: (1) virgil: Basic desktop acceleration, or (2) vGPU: More advanced acceleration but requires specific hardware, drivers and GPU vendor support.