The Ultimate Guide to VMWare and 3D Graphics

You’ve searched Google high and low, stumbled upon weird abbreviations like vSGA, vDGA, vGPU and other animals, scattered all over the internet.

Hours later, you’re still struggling to glue the pieces together, but all you have to show for it is a headache.

You simply wanted to know how VMWare vSphere enables you to deliver 3D graphics on your virtual machines.

Lucky for you, I’ve collected all the information I found and tested for our customer recently – into one guide.

So, after a deep dive into the topic I’ll share with you all the information I’ve collected.

When I say information I mean mostly theory, since in my opinion to be able to make a good choice you first need a solid understanding of the technology.

I’ll will not dedicate a section to talk about use cases, rather I’ll just mention some advantages and disadvantages regarding possible scenarios.

What is 3D Acceleration and why do I need it anyway?
When you hear people say 3D Acceleration that usually refer to Hardware 3D Acceleration.

Meaning, the utilizing of a dedicated piece of the hardware, aka GPU (Graphical Processing Unit), for graphical tasks.

Why do you need it?
Without a GPU your CPU will be forced to draw everything itself, and if you’re using rich graphical applications, it might heavily impact the overall performance.

Some more demanding applications, like 3D games and 3D rendering applications may not be working at all.

VSphere 3D Acceleration capabilities

Soft 3D
This is the most low-end solution, which does not require a physical GPU in the vSphere host. Rather, your 3D enabled desktops utilize the virtual machine’s CPU for rendering tasks.

Obviously Soft 3D is far from being ideal for heavy 3D applications, and since it provides limited DirectX and OpenGL support, some of them won’t work at all.

But it’s still a solid solution if you want to run applications that require some 3D, or support Windows Aero capabilities.

To be able to enjoy this lovely feature you need to have the SVGA 3D driver installed, the same one that is being installed when you install VMWare Tools on your virtual machine. You also need a remoting technology that can leverage this capability, but we’ll get into it later.

vSGA
To be able to activate this feature you need you have a graphic adapter installed in your vSphere host, then vSGA allows multiple virtual machines to share that adapter’s GPU for rendering tasks.

The SVGA driver is used here as well, just like with the Soft 3D, but now it can hand off renderings to a process called Xorg which in turn does the rendering on the GPU.

Think of the Xorg as an interface between the SVGA driver and your GPU. This method also requires that you install the correct vib driver for your adapter on the ESXi system.

For a virtual machine to get a share of the GPU it must also have some of the adapter’s video memory allocated to it. The amount of video memory you can allocate per virtual machine is limited to 512MB (If you can’t increase it to more than 128, upgrade the VM’s hardware version).

Half of this amount is reserved on the GPU memory, and the other half on the host RAM.

That means that if you have for example a GPU with 8GB RAM and you allocated 256MB to each one of your VMs, you’ll be able to support 64 VMs:

————-
8GB = 8192MB Total GPU memory
256MB video memory -> 256/2 allocated on the GPU memory = 128MB
8192/128 = 64 Virtual machines
————-

vSGA grants you decent hardware acceleration, but there is also non-negligible overhead that makes this solution not very suitable for heavy 3D applications.

Also, because it uses the SVGA 3D driver, it has limited support for DirectX and OpenGL – DirectX 9.0c and OpenGL 2.1

vDGA
We’re now getting to the heavy weaponry – vSphere ESXi provide you with the capability to pass-through the GPU to a virtual machine.

So now the virtual machine has direct access to the hardware, bypassing the hypervisor.

Since the VM now interacts directly with the hardware it will use the Vendor’s native driver for this GPU (must be installed manually), granting us the best performance and supports the latest APIs for graphics DirectX11 and OpenGL 4.1x.

But not everything is great. You can pass-through PCI adapters on a 1-1 basis, which means two virtual machines with vDGA enabled equals purchasing two graphic adapters.

Also most server boards are limited to four x16 PCI slots, what makes this solution not very scalable. Finally, you can’t vMotion VMs with PCI pass-through because they are bound to the hardware.

vGPU
This technology introduced by NVIDIA, really takes the advantages of vSGA and vDGA and combine them together.

In this mode multiple virtual machine gets a slice of the GPU, but unlike vSGA (and much like vDGA), they can send graphic commands directly to the GPU, also leveraging the native NVIDIA driver.

Each virtual machine assigned a vGPU by the GRID Manager software which is installed within the hypervisor, and from that point the virtual machine treats the vGPU as a physical GPU that has been pass-troughed by the hypervisor.

NVIDIA GRID vGPU is supported on NVIDIA GRID K2 and GRID K1 cards only right now, both implement multiple physical GPUs – GRID K1 has four GPUs with 192 processor cores and 4GB of memory each, while GRID K2 has two GPUs with 1536 processor cores (slightly slower clock speed) with 4GB of memory each.

That makes the K2 more performance oriented, while the K1 is more capacity oriented.

There are several types (also referred as profiles) of vGPUs that can be assigned to virtual machines, each with different characteristics. The following table lists the virtual GPU types:

Table 1 – vGPU Profiles

To sum it up vGPU is truly impressive, it gets great performance, supports the latest graphics APIs and scale very nicely.

But there are still some reasons why you might choose other solutions on vGPU. vDGA for example gives you slightly better performance compared to the K280Q profile, and vSGA gives you better sharing ratio in a more cost effective manner – vGPU requires Enterprise Plus license as well as VCenter installed.

How do Horizon View and Citrix XenDesktop fit in?
It turns out that it’s not enough to enable the graphic features on the host side.

You can’t just configure, GPU Pass-through (vDGA) for example, connect via RDP and run GTA V.

The reason for this is that you must have remoting protocol that supports vDGA. With RDP you’ll notice you don’t recognize the GPU from the remote session, and applications that require one will most likely fail to run.

That’s where Horizon View and XenDesktop comes in – both VDI solutions provide remote desktop protocols suitable for the task, and can leverage the vSphere graphics technologies.

In my opinion, that is the most confusing part, because when I started to look into this, it seemed to me like the features were shipped with Horizon View itself or perhaps available for it exclusively, and that’s not the case.

Obviously Horizon View is the most natural choice, since it’s also a VMWare product, and integration is best when you stay within the family, but bottom line is other VDI solutions and remoting technologies can also leverage some or all of the graphic features comes with VSphere as well.

A Word About Prerequisites
As you may realize the various features we have covered each comes with a different version of vSphere and is supported on different versions of Horizon View.

To see the prerequisites of each feature you should go to VMWare Compatibility Matrix and in the What are you looking for list box you can choose one the features and check for its prerequisites.

Soft 3D is not in the list because it’s not really something you enable or disable, it just works when no other technology is being used, assuming your remoting protocol support it.

It’s extremely important to note that your end device must also support the solution you’re going to implement.

Some people think that the device hardware is unimportant, they just need to connect to the environment and enjoy the server’s capabilities, right? The answer is NO.

If you’re going to deliver 3D rending over these virtual desktops, or even just play video in various qualities you must make sure you have enough bandwidth and a qualified CPU.

Once the server has finished rendering something, it sends the drawn screen as a bitmap over the network. If we’re talking about hardcore designers it can get to 100+Mbps of traffic.

As for the CPU, decoding and decompression of images takes processor time, and some processors are just too slow to process the images fast enough to deliver smooth user experience.

Conclusion
Finally I’d like to go back to the four technologies we’ve covered and summarize the pros and cons for each one:

Soft 3D:

Pros:

• No cost
• No hard limit for the number of users per CPU

Cons:

• Poor graphics performance
• Graphics API limited support
• Utilization of CPU for graphic tasks may impact overall performance

vSGA:

Pros:

• Low cost
• Good users-per-GPU ratio
• Good performance for basic 2D & 3D applications

Cons:

• Poor performance for heavy 3D applications
• Graphics API limited support

vDGA:

Pros:

• Best graphics performance
• Support the newest graphics APIs

Cons:

• High cost
• One to one users-to-GPU ratio
• Lose of the vMotion capability

vGPU:

Pros:

• Very good graphics performance
• Decent users-to-GPU ratio
• Support newest graphics APIs

Cons:

• High Cost

Table 2 – Technology Comparison

* Soft 3D doesn’t use a GPU

Hopefully, now you have better understanding of the whole concept, and you’re better equipped to start your research.