Inexpensive GPU Virtualization Options for Testing
For a new chapter in my ongoing series of talks and articles about browser performance I wanted to examine how key user experience metrics like page load time are dependent on available hardware resources. I prepared a VM and started my tests with a single CPU core and 2 GB of RAM, planning to gradually add more cores, more RAM and, eventually, a GPU. As it turned out, the latter is harder than anticipated.
Virtualizing a GPU – the Options
There seem to be many different ways to equip a VM with a GPU these days, but not all of them make sense for a test environment. Nvidia Grid, specifically, is pretty expensive, given that it requires specific professional GPUs and supported server hardware, unlocked by Grid software licenses.
Another variant that I did not find suitable: GPU-enabled VMs, e.g. from AWS or Azure. The reason being not even cost (I would only have used the VM for a dozen hours or so), but flexibility (I had to be able to change the VM’s hardware configuration).
With Nvidia Grid and a cloud VM out of the way, I was left with the following options. Please note that I was looking for a simple and inexpensive solution.
- Client Hyper-V with RemoteFX
- Client Hyper-V with direct device assignment (DDA)
- VMware Workstation
Let’s take a look at each of these in turn.
Client Hyper-V with RemoteFX
Configuration
RemoteFX GPU virtualization has been available in Windows 10 Client Hyper-V since version 1511. Some docs state that the Enterprise SKU of Windows 10 is required in the guest, but I did not find that to be correct: Pro and Enterprise gave identical results.
To enable RemoteFX GPU virtualization:
- Host: in Hyper-V settings, enable a physical GPU for use with RemoteFX
- Guest: in the VM’s settings, add a RemoteFX 3D Video Adapter to the VM
No need to care about GPU drivers in the VM: they are part of Hyper-V Integration Services.
Operation
With the above steps completed, you will see a virtual GPU in the VM (Microsoft RemoteFX Graphics Device – WDDM):
DXDiag seems to be quite happy with it:
Chrome not so much:
Also, there is no GPU in Task Manager:
Verdict
RemoteFX does not map (part of) the physical GPU into the VM. Instead, it virtualizes certain DirectX APIs. That may be enough for some uses cases, but Chrome is looking for something different and consequently sticks to software rendering.
By the way, a good indicator that there is no “real” GPU available in the VM is that you do not need to install GPU vendor drivers.
Client Hyper-V with Direct Device Assignment (DDA)
DDA Requirements
DDA maps a physical GPU into a VM. While it is documented only for Windows Server I thought it just might work with Windows 10, too.
With DDA, the VM “sees” a real GPU. Therefore vendor drivers need to be installed in the VM.
DDA only works if the host machine’s BIOS supports SR-IOV. In other words, the BIOS must support relinquishing control of the PCI Express bus to the OS. That, unfortunately, is a capability typically only found in server hardware. SR-IOV is not to be confused with VT-d, which is typically found in consumer hardware but which is not to sufficient to make DDA work.
DDA and Licensing
Even if you have a machine that meets the hardware requirements for DDA outlined above, you may run into a problem of a very different nature: Nvidia’s consumer cards cannot be used because of restrictions in the driver. Nvidia’s Grid cards, on the other hand, require software licenses in addition to the professional-grade hardware. Rachel Berry has a good overview of Nvidia Grid licensing.
AMD GPUs (purportedly) do support DDA, but I did not test that.
VMware Workstation
Configuration
The first thing you may notice after installing VMware Workstation is that it does not work if Hyper-V is enabled. If you want to keep using Hyper-V your best option is to create a new boot menu entry with Hyper-V disabled. That way you can switch between Hyper-V and VMware Workstation simply by rebooting. From Stack Overflow:
C:\>bcdedit /copy {current} /d "No Hyper-V"
The entry was successfully copied to {ff-23-113-824e-5c5144ea}.
C:\>bcdedit /set {ff-23-113-824e-5c5144ea} hypervisorlaunchtype off
The operation completed successfully.
As with RemoteFX, there is no need to care about GPU drivers in the VM: they are part of VMware Tools. This indicates that the concept is similar in nature to RemoteFX.
Operation
The virtual GPU you will see in the VM is of the type VMware SVGA 3D:
Again, DXDiag is happy:
Again, Chrome not so much:
As with RemoteFX, there is no GPU in Task Manager:
Verdict
From an application’s point of view, VMware Workstation GPU virtualization is similar to RemoteFX: potentially good enough for some use cases, but there is no “real” GPU in the VM.
Conclusion
It’s 2018. This should be easier!
GPU virtualization is most definitely not mainstream yet. Currently, server hardware with either AMD or Nvidia Grid GPUs is required. That makes testing unnecessarily difficult and expensive.
3 Comments
Hi Helge,
It is expected for GPU to be missing in Task Manager since neither driver is WDDM 2+.
When you tested RemoteFX vGPU, did you try switching to Enhanced Session and/or connecting via regular rdp? I’m unsure about the build you were using but when I’ve seen the Chrome issue you describe that was enough to toggle it into working mode. This *may* be related to the bug that was recently fixed in 1803 whereby you cannot reconnect to RemoteFX vGPU session. From your screenshot you were testing with early 1709–perhaps the latest build includes same fix that is part of latest 1803.
I just did quick test with latest 1803 Enterprise and Chrome showed Hardware accelerated with RemoteFX vGPU adapter.
Hi Helge,
Check out GCP for GPU virtualization. They give you a lot more flexibility over the VM customization with GPUs; instead of them being preset machine configurations. Be aware though – certain regions only have certain types of GPUs. You’ll have to click through the region that supports the GPU you’re looking for.
Things are a bit better with VMware Player 15.x – Chrome is definitely happier although there are still gaps:
*Graphics Feature Status*
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Software only. Hardware acceleration disabled
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Out-of-process Rasterization: Unavailable
Hardware Protected Video Decode: Unavailable
Rasterization: Unavailable
Skia Deferred Display List: Disabled
Skia Renderer: Disabled
Surface Control: Disabled
Surface Synchronization: Enabled
Video Decode: Hardware accelerated
Viz Service Display Compositor: Enabled
WebGL: Hardware accelerated but at reduced performance
WebGL2: Hardware accelerated but at reduced performance