This content is part of the Essential Guide: Everything you need to know about GPU virtualization

A tale of two hardware acceleration methods: Protocol vs. GPU offload

There are two ways hardware acceleration can improve virtual desktop performance: offloading GPU processing or offloading the remote display protocol.

To improve virtual desktop performance, should you use protocol offload or GPU offload? It doesn't take a game of rock paper scissors to decide. In fact, you don't have to decide at all -- you can use both kinds of hardware acceleration if you want to.

Ultimately, the topic of protocol offload versus GPU offload isn't as complicated as it may appear. First things first -- you don't have to choose one or the other. In fact, there may be times when using both is the only way you will get the virtual desktop performance you need. That said, let's examine each of these hardware acceleration options as they relate to VMware Horizon View, and what problems they are intended to fix.

The default PC over IP (PCoIP) protocol stack that most Horizon View users have is a software implementation that not only handles the encapsulation of communications to and from the VMware host, but it also provides codec-independent rendering, plus graphic and audio stream delivery. PCoIP is a feature-rich protocol in its ability to adapt to latency and bandwidth requirements, and to address some of the shortcomings of prior virtual or remote desktop tools, such as USB redirection, printing and local resource access.

The problem is that rendering and encapsulating the multimedia elements of a virtual desktop is a CPU-heavy process. Because the measure for success in a virtual desktop infrastructure (VDI) deployment is typically the desktop performance and the user experience it delivers, it's critical to reduce that CPU consumption.

Look to offloading to improve performance

Protocol offload smooths out CPU performance in virtual desktops. At the software level, it offloads the protocol encapsulation from the virtual machine (VM) instance to a dedicated card installed in the host itself, such as Terradici's APEX 2800 hardware accelerator. This makes it so the CPU cycles in the VM itself are tasked to handle the user applications -- as they should be. Dedicated hardware handles "keeping the lights on" and making the connection work efficiently.

You may be wondering: If the protocol offload card is so great, why do I ever need a GPU offload card?

GPU offload, such as NVIDIA GRID, is a purpose-built card designed to accelerate specific, complex graphics requests from a virtual desktop and offload them to a hardware GPU. The GRID card does for graphics what the APEX card does for the PCoIP protocol: It frees up CPU cycles in the virtual desktop by moving them to GPU hardware specifically designed to process CPU.

But there is something you need to know about the GRID card: It only offloads specific types of graphics, such as those generated by DirectX 9, 10 or 11, and anything that's OpenGL 4.4. That's not a bad thing, however. Those are the protocols that most 3-D applications use, and the rendering would normally bring VDI to its knees.

Once rendered, all of the output from the card is encoded as H.264. The H.264 standard allows for some very smooth and refined graphical output but, overall, it's not terribly efficient. Ultimately, it will still have to be sent to the endpoint via PCoIP, which can result in performance issues under load. If only there was a way to offload all that PCoIP traffic … You see where I'm going? You can use both kinds of hardware acceleration to achieve an excellent 3-D experience while also keeping CPU spikes to a minimum within the VM. This will lead to a far better experience for the end user.

Now you're probably thinking: To get what I need, I have to buy both? For every host in my environment? That's not quite what I'm saying. The bottom line is that deciding which card to use is about understanding your particular VDI implementation.

Example 1: You have more resources than you need for your user base, so you can afford to oversize CPU in your VMs a little, and your primary application is a small group of CAD developers who are all local to the network (so bandwidth isn't really an issue). You could set up a small cluster of hosts for your users and only buy GPU offload cards for those specific hosts. In this case, it's OK to have CPU handle the card's output delivery via PCoIP because there's enough CPU. Also, you're not buying a card for every host because you only need them for the cluster that serves the CAD team.

Example 2: You use VDI for a remote sales force or a call center that doesn't need video acceleration. You also want your executive team to use VDI for mobility, but you are afraid that a degraded video experience on will upset them. In this situation, you could select the APEX card and load it into the hosts that service the executives. This accelerates their more standard video needs because the CPU won't spike as graphics are rendered. Additionally, they will have a more consistent experience with remote connections because the bandwidth requirements won't fluctuate as wildly.

If you are trying to streamline your user experience and improve virtual desktop performance with protocol or GPU offload, then first figure out the details of the use case and then determine what kind of hardware acceleration you need. It could be one or the other or it could be both. Regardless, offload cards can make a huge difference in end-user experience.

If you are trying to accelerate the desktop, that's obviously because it's underperforming for your needs. It's incredibly important to also examine the other aspects of your VDI environment prior to jumping directly to offload. Is your storage bottlenecked? Is your density per host too high? Is your master image optimized for Horizon View? Are your endpoints running the correct version of the VDI client? Any of these could be the genesis of your issues. Jumping right to offload could be more of a bandaid than a true fix if you aren't careful.

Dig Deeper on Virtual desktop infrastructure and architecture