It’s time for me to admit something; while I have been sharing quite a bit in blogs and research lately around high end graphic technologies with virtual desktops, I’ve been quiet on some fronts, specifically shared graphics technologies. The reason I haven’t said much is that I haven’t been impressed by most of the technology that’s been out there. I have known for the past two years that better technology is coming so I decided to focus on the good news (typically GPU pass through technologies) as it became public and not blog or tweet, or just rant about what I really want, because up until now what I want didn’t exist.

Organizations that I talk to who are interested in doing high end engineering workloads on virtual desktops have had very few options over the years. The options that have been slowly showing up for the past few years had very little scale (direct GPU mapping) or had a less than stellar performance. However with the release of NVIDIA’s GRID vGPU platform I’ve seen for the first time a solution that is designed to scale better and also deliver a rich user experience. I’ve spent the good part of a year constantly testing these technologies and with the release of XenDesktop 7.1 I’ve finally been able to run a working test that I can publicly demonstrate, so without further ado I give you GRID vGPU on XenServer vs vSGA on vSphere.

3D World Demo:

3D Model Demo:

Now with new technology comes more confusion so I wanted to end this blog with some generic ways to understand the different technologies that are out there:

GPU pass through – All this does is pass the PCIe based GPU directly into the VM. The native graphic drivers for the GPU are installed and you should get the native graphic performance with that card.

Shared Virtualized GPU – Instead of passing a GPU directly to the VM a hypervisor sits between the VM and the GPU. This is very similar to how we have been virtualizing the CPU for server/desktop virtualization.

GPU Emulation – Unlike Shared Virtualized GPU there is no hypervisor layer that abstracts the physical hardware to the virtual hardware. Instead a resource manager carves up the GPU and passes it to individual VMs. It’s very similar to GPU pass through but in this model the GPU can be shared.

Software-based GPU – Instead of having a hardware GPU a video driver is created that uses the CPU as the GPU, as you can imagine this doesn’t give very good performance for high end tasks but may be enough for simple things. (This is sometimes called software rasterization)

RDS GPU Sharing – RDS GPU sharing uses GPU pass through (the first bullet) into a RDS VM, because RDS is a shared Windows kernel, multiple sessions can use the same GPU.

In the videos above I was comparing NVIDIA’s technology which I’ve created the new category of “GPU Emulation” to the shared virtualized GPU technology used in VMware vSphere. I created the new term because there are fundamental differences between a “virtualized GPU” and how the GRID vGPU technology actually works. I’m not going to get into these differences on the blog but you are more than welcome to call me if you are a Gartner client.

Update 1: It has come to my attention that my demo has created an assumption that XenDesktop running of vSphere is what’s causing the graphic performance issues. This is not the case, even if VMware’s Horizon View was running on top of vSphere the performance would be identical.

Update 2: I’ve run some additional testing at scale and while the vGPU does do a better job than vSGA, it is no where near as drastic as my videos show. In fact as soon as you do two VMs running on the same PCIe bus the performance takes a significant hit.

There is a technology from Citrix RemotePC, where you take the existing bare metal machine with a GPU and get access to the bare metal “VDI” from any device. This technology have been used for many clients before GPU pass-through was introduced, which have been the replacement to reduce the TCO and lately vGPU which reduce the TCO even more for native experience.

You can create bare metal RDS GPU Sharing without GPU pass through. With GPU Pass-through there is a small overhead of virtualization using a Hypervisor like Xen, Vsphere, Hyper-V. Many uses the “non GPU pass-through” option to get pure bare metal performance and share the GPU in a RDS/Citrix environment.

Great covering gunnar. I was wondering about your update 2, is there a significant decrease in performance on the vGPU on citrix that levels the competition with vSGA on vmware when shared on 2 or more vm´s on both systems? Meaning of course that vmware runs 2 or more vm´s too of course.

Hi Gunnar,
There is one thing that I cannot seem to get a clear answer on from anyone: If I am deploying a XenDesktop 7.1 on vSphere 5.1 or higher, will vGPU work? VMware tends to discuss only View on vSphere while Citrix talks only about XenDesktop on XenServer. Could you clarify this for us please?
Thank you in advance!

@Kai: And it seems this solution will not support VMWare vSphere and MS hyper-V soon
Update: With windows 2012 on physical server, you can provide only upto 126 MB vGPU RAM to a virtual machine. However, with windows 2016, a 2GB GPU can be provided to single VM. You can also assign it in parts, say, 512 MB per VM, 1 GB per VM. Obviously, with discrete device assignment, a GPU can be attached as pass through device as well.

Excellent post. I used to be checking constantly this blog and I’m impressed!
Very useful info particularly the ultimate part 🙂 I handle such information a lot.
I was looking for this certain information for
a very lengthy time. Thank you and good luck.

About

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.