The second half of 2013 has seen tremendous buzz around a compelling new capability in desktop virtualization; virtualized graphics processing.
I’ve posted before about how you need to prepare for the arrival of hardware GPU sharing, and there have been some excellent blogs covering updates to HDX 3D Pro Graphics with XenDesktop 7.1. However, you know you’re on to something big when industry analysts like Gunnar Berger are posting comparisons of different graphics models.
The good news is that on December 16th, 2013 Citrix and NVIDIA will be releasing full support for XenDesktop 7.1 HDX 3D Pro with XenServer 6.2 SP1 to deliver true hardware GPU sharing with NVIDIA GRID K1 and K2 cards.
What I’d like to do is both consolidate some of the information out there, and explain when a given technology might be a better choice. After all we’re now entering a point in time when choice of hypervisor is driven not by personal preference, but by the type of workload it is optimized to deliver. In this case, that workload is one which has high performance graphic requirements, and which must be securely delivered from a data center in a virtualized manner.
Dedicated access models
The easiest VDI graphics model is the direct access method. In a direct access method, a given GPU is assigned to a specific VM, and that VM has full access to the capabilities of the card. If you are a vSphere fan, then you’ll recognize this model as vDGA and if you’re a XenServer fan this is called GPU pass-through.
Regardless of the hypervisor, you are interacting with the underlying video card via drivers from the graphics chipset vendor, and any shared access is occurring within the VM and its application stack. Due to the direct assignment of the GPU to specific VMs, shared access to the GPU across VMs isn’t possible, but each VM can be a multi-user Windows Server RDS machine.
Now the beauty of this model is that you do indeed get access to the full capabilities of the video card but, in the case of single-user Windows desktop VMs, this comes at an additional cost; user density. Effectively the maximum number of VMs you can run is limited by the number of GPUs you can put in a server. Obviously you can overload the server with non-graphics VMs, but since the objective is to maximize the performance of the graphics-heavy applications, overloading the server can create CPU starvation within the graphics applications.
Shared access models
When it comes to providing shared access to a GPU by multiple single user VMs, there really are three distinct models available; emulation, API intercept, and hardware GPU sharing. While there is nothing inherently wrong with any of these solutions, there definitely is a tradeoff in terms of performance and scalability. In each of these approaches there is a cooperative nature between drivers in the hypervisor and drivers in the guest to deliver on a specific use case.
VMware vSGA
Virtual Shared Graphics Access (vSGA) is a VMware solution designed to provide shared access to a GPU for the purposes of delivering HTML5, WebGL, Web 2.0 applications and other rich media type applications.
Within each guest there is a VMware driver which in turn interfaces with a GPU specific driver in vSphere to provide shared access to the frame buffers in the GPU. The VMware driver is responsible for providing emulated access to the underlying GPU hardware within the operating system GPU stack. This means that applications specifically designed to function with an NVIDIA driver will need to be recertified against the VMware driver, and that advanced capabilities present in the operating system GPU stack may not be available to applications.
vSGA is limited to DirectX 9.0c (released in 2004)and OpenGL 2.1 (released in 2006), and in their Graphics Acceleration Deployment Guide VMware indicates that if newer versions are required; “applications requiring newer versions might not perform or function correctly”, and that certain applications are only certified for “reviewers and lightweight use cases”. In such scenarios, VMware recommends vDGA.
Microsoft RemoteFX vGPU
The RemoteFX technology stack includes the ability to deliver virtualized GPU access when Hyper-V is used as the hypervisor. RemoteFX vGPU is primarily designed to support the Windows Aero experience in a VDI scenario, and with Windows Server 2012 can function without a physical GPU.
In order to leverage RemoteFX vGPU, your physical GPU must have DirectX 11.1 drivers available to it, and vGPU will present DirectX 9 or DirectX 11 to your VM. Since DirectX is the primary API for graphics operation, and since the driver in the Hyper-V primary partition provides a super-set of functions, RemoteFX can proxy graphics calls between the guest and host to deliver an optimized graphics experience for DirectX enabled applications which don’t require full access to a GPU. XenDesktop VDI supports RemoteFX vGPU when used with the RDP protocol and the Citrix Receiver for Windows.
XenServer vGPU
In XenServer vGPU, the split driver model used by XenServer allows an NVIDIA driver to be loaded in the XenServer control domain, and an NVIDIA driver to be loaded in the guest VM. This has the primary benefit of ensuring GRID card access is properly managed using NVIDIA drivers, and from the user perspective that applications which are certified for NVIDIA drivers continue to function as designed; without modification. One of the immediate benefits of this approach is that NVIDIA drivers natively support the latest versions of OpenGL and DirectX.
If you would like to see the current list of validated applications for vGPU deployment on XenDesktop 7.1 HDX 3D Pro, please reference the NVIDIA Remote Workstation Certification List.
Ultimately, the choice is yours to make. Each of these solutions have their strengths, but when it comes to providing the best possible graphics experience your choice boils down to either a direct access model, or XenServer vGPU with NVIDIA GRID powering XenDesktop HDX 3D Pro.
Whether you are supporting architects, engineers, designers, graphic artists, or workers needing access to 3D data models; we now offer you a solution which provides all the benefits of secure remote access without compromising graphics fidelity or user density.