The One with the GPU Graphics Performance

Those who follow my articles know that I have always been a big supporter of VDI as a method to simplify desktop administration, reduce costs, improve user experience, increase productivity, provide remote access and enable BYOD, and provide an effective disaster recovery solution for workspaces. Whilst VDI has delivered on these promises, there has been previously room for improvement in a few areas.

Brian Madden cleverly highlights in his article Desktop Virtualization in 2015: What’s coming, what do we need? He makes the point that vendors have now delivered most of the desired features to enable VDI to be a successful replacement for physical desktops. In particular, one of the areas that needed most attention was graphics performance.

These days we have better remoting protocols, which support multimedia redirection, lower bandwidth and higher latencies. We also have full support for physical GPUs (Graphics Processing Units) installed in each hypervisor that can be used on a 1:1 basis or shared across multiple virtual desktops, increasing graphics performance and user experience.

There are other industry innovations in other areas like storage and image management that are making administrators life much easier, but for this article I would like to focus on graphics performance because there has been some public discussions and perhaps misunderstandings about the use of the technology.

Graphics Performance is critical in VDI deployments and I have extensively written in the past about VDI User Experience and User Acceptance and how they play a big part in successful deployments. Furthermore, it’s not coincidence that the most popular article in my blog for the past couple years was How to improve VDI with Hardware Accelerated 3D Graphics. Administrators and users are both concerned about obtaining the best user experience, just like the most recent laptops with advanced Graphics Processing Units.

Citrix is supporting shared vGPU with XenServer today and VMware will be supporting it with the upcoming vSphere 6.0 release. Additionally, there are some interesting upcoming technologies that will enable local GPU in our tablets and laptops to decode h.264 via silicon instead of software. Gunnar Berger does an excellent job explaining how this will work here

For VDI deployments vGPU is a ‘must have’ when working with 3D imaging applications such as CAD, CATIA, MAYA, Lumion and others. vGPU may also be required for medical applications when visualizing tri-dimensional images. VDI with vGPU is a fantastic replacement for physical dedicated graphics workstations. Even Microsoft Office and Internet Explorer are now making use of vGPU if the card is available on the server executing the virtual desktop.

Some say that it’s just a matter of time before GPUs are available in every device, and I agree with them. I believe GPU’s will eventually be fully baked into server motherboards and CPUs, but that is just not happening yet.


However, I do not agree with the position that some are taking, saying that vGPU is a ‘must have’ for every single VDI deployment.


Now, before I move forward I need to clarify that everything I am writing here is my own opinion about the subject and that does not necessarily represent my employer positioning about the subject; as matter of fact many of my colleagues think differently than me and I respect that. However, I have always been open about my thoughts and will guide my readers in the direction I believe is the correct one.

While analyzing market data we will find out that GPU penetration is approximately 1-3% of the entire VDI market and the VDI market grows at approximately 10-15% CAGR. Just this data alone points me to the conclusion that ‘today’ VDI is being successfully deployed without vGPU. That also means that Software 3D Rendering is in use for the large majority of VDI deployments. Maybe the GPU market penetration is so low because Shared GPU support has been only available for XenServer; however in conversation with one of the GPU vendors I was told that the GPU market will peak at 10% of the entire VDI market. I personally think it will be bigger overtime.


Screen Shot 2015-01-11 at 9.39.40 PM

Sr. Director, Product Management for Clients and Protocols


Many of the very large deployments I see happening today, with anything between 1K to 90K desktops, do not have major GPU requirements. They are actually being sized for single vCPU and 1.5-2GB RAM on average, for better or worse!

I clearly see the user experience benefits that GPU provides, but I also see a large majority of VDI workloads where ‘today’ GPU is a nice addition that increase graphics performance, but it is not a requirement. Think call centers (the biggest VDI consumer today), hospitals (when imaging is not required), task workers (where only Office is required), Federal and GOV (where security is driving the deployment) etc.

GPUs are somewhat expensive today (approximately $2K per card per server to support 64 desktops with 128MB vRAM per user) and may reduce the overall VDI project ROI. However, I have to admit that I was pleasantly surprised with the price drop. Last time I looked at them they were ~$7K a unit.

The use of GPU certainly offloads CPU processing cycles, and some will argue that this allows for increased consolidation. That is true, but to implement GPUs one would need servers with larger datacenter space footprint, additional power consumption and additional cooling. These servers, generally speaking, can support more memory allowing more virtual desktop to be consolidated, but also increasing failure domains in case of a server outage. Also, when a single GPU is added per server one would be creating SPOF (single point of failures), and also not allowing for vMotion operations therefore creating problems during server maintenance tasks (I believe XenMotion is supported, but someone please correct me if I am wrong).

As of today, even when graphics rendering is offloaded to GPU, the protocol encoding still happens via CPU and software. That is deemed to change in the future, but for now the offload is not complete.


Another point I would like to highlight is that with more graphics processing your systems will be delivering more graphic data at a faster rate via the network, increasing the amount of bandwidth required per user. This certainly is not a problem when on local networks, but more bandwidth also means additional WAN costs (OPEX).

Here is an interesting paper from VMware on use of GPU with Horizon View, however it doesn’t have consolidation comparisons between a GPU and a non-GPU deployment. Worth reading anyway: VMware Horizon 6 and Hardware Accelerated 3D Graphics – Performance and Best Practices.

Another change about to happen is the move from Ivy Bridge processor to Haswell. Both are very similar chips with the differences being mostly related to architecture. That being said, there is a 5-7% increase in performance that will help to offload CPU if your VDI deployment is bound by CPU today.


I am always in favor of better user experience and best of breed graphics and performance, but I am also of the opinion that the large majority of workloads today can do just fine with Software 3D rendering; and market data tell us that this is what is happening today. It’s up to you as a business decision maker to analyze and make a decision if you want to make the investment now, later or never.

I could perhaps create a similar parallel with electric cars such as the amazing Tesla being best of breed; however it’s up to you to decide when it’s time to move to an electric car, and you may decide to move to a cheaper model for a number of different reasons.

In the GPU topic, perhaps a different solution would be to have nodes with GPU for users requiring more graphics performance, and nodes without GPU, but this approach will also increase the administration efforts involved in maintaining the platform.


In Summary…

The developments around improving the VDI experience have really matured the technology and there are now lots of options of how to deploy VDI. This is great news for IT organizations. From the stance of architecting and managing many VDI implementations, I think the approach we should take with any deployment is to understand requirements and do a true opportunity cost/benefit analysis of including vGPU on a case-by-case basis rather than a cookie cutter approach. At the end of the day choice is good and especially good for consumers.


… For those that didn’t notice, the title is a reference to the american TV series Friends and their episode titles.


This article was first published by Andre Leibovici (@andreleibovici) at


3 pings

Skip to comment form

  1. Just a quick update note – when I say VDI deployments are not using pGPU I am not infering that Software 3D Acceleration is being or should be used. In most cases no 3D acceleration is being used at all. The three options are No Acceleration, Software Acceleration and Hardware Acceleration.

    Thomas Poppelgaard, a Citrix specialist big into GPU acceleration, tells me that it’s actually better to run VDI with NO acceleration than with Software 3D Acceleration.

    Does anyone have any data on that?

    • forbsy on 01/12/2015 at 11:49 am

    I deploy a bunch of VDI. I can tell you that full GPU support is a very important step for VDI. I wouldn’t allow the hypervisor to offload the added CPU. I’d always pair up the GPU card with an APEX2800 PCoIP card for the PCoIP encoding offload. It’s about time VMware supported vGPU – which will support HA and vMotion.

  2. forbsy, thanks for your comment. I have been told by someone from VMware PM team that vMotion is not going to be supported for Shared GPU, at least with vSphere 6.0. Would be good to confirm.

    Are you confident that XenMotion is supported with Shared GPU? This article from July, 2014 ( says the oposite.

    • f.vanderploeg on 01/19/2015 at 1:32 am

    Hi Andre,

    Nice article, good read. I fully agree, GPU deployment should only be done if the use-case is there. (CAD/CAM vs Office workloads)

    XenMotion is NOT supported for vGPU-enabled VMs. Hopefully in the future, and the latest vGPU profile addition (K280Q) could enable XenServer to support those scenarios.

    A small note:
    “Another point I would like to highlight is that with more graphics processing your systems will be delivering more graphic data at a faster rate via the network, increasing the amount of bandwidth required per user.”

    That’s not entirely true, I’ve done some measurements with HDX 3D Pro vs. Non-HDX 3D Pro sessions. The bandwidth savings can be up to 68%:

  3. Andre,

    At the end of the day you’ve made one more case for conducting a proper assessment of the end user environment before moving on with a PoC or Pilot. Lakeside Software’s Systrack7 can now track GPU performance for both physical and virtual desktops. It still surprises me how many folks don’t even consider an assessment when they know less about their end users than anything else in their IT environment.

  4. @f.vanderploeg: XenMotion is NOT supported for vGPU-enabled VMs. Hopefully in the future, and the latest vGPU profile addition (K280Q) could enable XenServer to support those scenarios.
    With windows 2016, MS now supports OpenGL and CUDA.
    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.

  1. […] GPU for example, there has been a lot of discussion on this particular item, let’s just say I agree with Andre on this one. And although all the hardware being physical and on a one to one basis (and that’s […]

  2. […] The One with the GPU Graphics Performance […]

  3. […] The One with the GPU Graphics Performance […]

Comments have been disabled.