During a presentation that I gave at the E2EVC Conference in Barcelona a few weeks ago, I spoke of a situation whereby the addition of a software GPU into a virtual desktop can cause Microsoft Office, Internet Explorer, Firefox and Chrome to all leverage this software GPU for advanced rendering of 3D graphics. When a GPU is normally present on a physical workstation, this is a great way to accelerate the performance of these applications on a desktop computer. When you’re using these products in a virtual desktop environment, things change slightly. All of the major virtual desktop solutions (VMware View, Citrix XenDesktop and Microsoft RDVH) enable a software GPU in the virtual desktop session when their VM enlightenment drivers are installed into the virtual desktop image. This software GPU enables things like Windows Aero to function even when a physical GPU isn’t present in the virtual machine. This is generally a good thing as it allows for a “like-physical” desktop experience. However, emulating a real GPU in software (CPU) takes its toll from a performance perspective. Ultimately, it can result in a significant degradation of user experience as well as a reduction in scalability of the virtual desktop platform. In many cases, that scalability can be restored, by following one of two paths:
1) Actually deploy a GPU in your servers and leverage the GPU for offloading the GPU instructions from these applications. NVidia GRID vGPU technology is a method that can be used to generate good scalability and great performance / economics.
2) Disable the use of accelerated graphics in Office, IE, Firefox, Chrome, etc which forces them to use software rendering in lieu of the software emulated GPU (essentially you’re going to use software rendering in both cases, only not pretending to be a GPU saves significant CPU). This doesn’t provide the benefit of the GPU acceleration, but if you don’t have a GPU in the host machines anyway, this will preserve some scalability.
How each application implements acceleration differs, but here’s a few screenshots to indicate where this setting is disabled so that software rendering is used instead of software GPU emulation:
Internet Explorer 11 (and 9 and 10 as well):
Choose Internet Options, then under Accelerated Graphics check the box for “Use software rendering instead of GPU rendering”
Google Chrome:
Click on Settings, then “Show advanced Settings”, then de-select “Use hardware acceleration when available”
Firefox:
Click on Tools->Options. Then click on the Advanced tab across the top, then General Tab below. Uncheck “Use hardware acceleration when available” as shown here.
Microsoft Office 2013 (applies to 2010 as well):
Open Microsoft Word and choose File->Options. Then click on the Advanced item in the left window pane, scroll down to the Display section and select / check the box for “Disable hardware graphics acceleration”
Controlled Deployment:
All of this information is great and all, but you probably don’t want to instruct every user on how to change these settings. Instead, it’s easier to just inject these settings for all users on your virtual desktop platform. Many of these settings manipulate registry values in the HKEY_CURRENT_USER registry hive or store preferences in the user profile and therefore it’s not something that you can turn on/off in machine registry modifications or GPO. However, you can either adjust these in your default user profile, or what I prefer to do is just build a set of Group Policy Preferences entries to adjust these for every user as they logon to my virtual desktop platform. Unfortunately, Chrome and Firefox cannot be managed this way, but there are ways of solving those as well. Here are the relevant settings you’ll need to incorporate to disable software GPU emulation in these apps.
IE 9, 10, 11:
Key: HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main
Value: UseSWRender
Type: REG_DWORD
Data: 0x1
Office 2010:
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Gfx
Value: DisableHardware
Type: REG_DWORD
Data: 0x1
Office 2013:
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Graphics
Value: DisableHardwareAcceleration
Type: REG_DWORD
Data: 0x1
Google Chrome:
Unfortunately Google Chrome does not have a simple registry entry that can be used to alter its use of a software GPU. Google Chrome stores its preferences into files in the Local AppData folder of the user profile. There are, however, several ways that you can carry out this change:
1) Ensure that any place where Google Chrome can be launched from you’ve appended the –disable-gpu switch to the end of the chrome.exe command line. This will make sure a software renderer is used.
2) Download and implement the Google Chrome AD GPO templates to adjust the behavior of Chrome when used in an AD GPO environment. Details on this process can be found here.
3) Deploy Chrome to your users using a master_preferences file. This is only useful if Chrome isn’t already deployed. Details on this process can be found here.
4) Configure a managed deployment of Google Chrome using the Google Apps Admin Console. Details on this process can be found here.
Special thanks to @scott_matteson for some great write-ups on Google Chrome deployments that I’ve linked above.
Firefox:
There are multiple ways to implement an override for Firefox, but like Google Chrome the settings that are active for Firefox are not maintained within registry entries, but rather are stored in preferences files in the user profile (at least with Firefox it’s a roaming folder location). The two settings that you’ll want to disable are named gfx.direct2d.disabled and layers.acceleration.disabled. Like Google Chrome there are multiple ways to alter the preferences:
1) Deploy Firefox with a pre-configured set of preferences. See here for more details.
2) Create a all-companyname.js or user.js preferences override that Firefox will leverage when launched to build a default user configuration. More details on this here. The preference entries you want to disable hardware acceleration are:
user_pref(“gfx.direct2d.disabled”, true);
user_pref(“layers.acceleration.disabled”, true);
3) Jeremy Moskowitz (Group Policy MVP) has added support for Firefox settings into his PolicyPak product. While I have not personally verified that the hardware acceleration setting is included, I assume that it’s in there. Details on Jeremy’s PolicyPak configuration for Firefox can be found here. This method will allow you to use GPO to manage Firefox settings. NOTE: There have been various add-ins for Firefox over the years that allowed for GPO management, but they have been somewhat problematic. If you want GPO-style management, go with PolicyPak.
That should be enough information to get you started. I’m currently extremely busy in my new career, but hopefully I’ll get some time to put together some videos to illustrate the impact of these settings differences in the coming weeks.
Ryan Gallier says
This is awesome, Shawn. Do you have any numbers on how much the CPU is degraded by trying to emulate GPU functions?
shawn says
Ryan – I do not have specific numbers on the reduction of scale, but it’s not only a scale reduction that’s the issue, it’s also a user experience thing as well. It’s difficult to measure this exactly as it sort of depends on the URLs accessed and the types of documents used. I’m hoping to gather some good examples to illustrate with some videos when I get some free time. Hopefully in a few weeks.
markuszehnle says
Thank you for the great article!
You’re talking about vGPU, is there also an enhancement of putting in a “normal” GPU in shared mode according to CPU renderd graphics?
shawn says
Markus,
Any method of providing a “real GPU” to virtual desktops would be better than providing software GPU. So passthrough GPU on a 1:1 basis or passthrough GPU on a shared RDSH/XenApp platform are other ways of accomplishing the same thing. However, in a VDI context your only options are vGPU or Passthrough GPU. Passthrough GPU can be done, but given it’s 1:1 nature has severely less economics and hence why I recommend vGPU as the strategic solution.
Thanks for your comment.
MaxTrottier says
Great to see you blog again Shawn! 🙂
DStafford says
For years I’ve looked at those checkboxes and wondered why anyone would ever want to disable hardware rendering. – Debugging a graphics driver was the only reason I could come up with. You’ve given me a great reason! Terrific article.
shawn says
David –
There are certain circumstances where turning this off is helpful for troubleshooting, but generally speaking it’s most important to maintain scalability in VDI platforms where you have a software GPU present. Thanks for the comment.
Jeroen van de Kamp says
For office that GPU setting only applies when you actually have a GPU. Without a GPU it simply cannot use hardware accelerated rendering. As a result, enabling this option has zero impact in hosted session without GPU accelaration. This is tested and published in the VRC Office white paper.
shawn says
Jeroen,
Thanks for stopping by and adding your comments. I recall seeing this in the VRC whitepaper. Are you absolutely certain that your testing included a WDDM (i.e. Soft3D) driver when your testing was done? XenDesktop has often deployed a non-Aero driver in it’s implementations until fairly recently. If you weren’t using the WDDM driver, then you wouldn’t have Software GPU and I would concur with you that toggling this value will make zero difference. However, if you have a software GPU I believe this is still impactful. At least I had a customer that insisted this was causing them problems until they turned it off on Office 2013 (this was XenDesktop 7.1 which uses WDDM by default when you run Aero). Should you still have the configuration details available, I would be interested in seeing whether or not you were using Aero (not Aero redirection, but host side Aero rendering via WDDM). Thanks.
Chas Purewall says
Nice Blog Shawn!
Nathan says
The problem with disabling GPU using the command line switch with Chrome is that NOBODY IS LAUNCHING CHROME FROM A COMMAND LINE. In VDI or Shared desktops they launch it from an icon. That makes modifying the icon quite difficult on a global scale since users will normally launch it from the taskbar, where icon properties cannot be globally managed.
shawn says
People are launching it from a command line when it’s a published application. If you’re using published desktops, then you’re correct. This is not the proper method for managing it.
Ryan Gallier says
It’s easy enough to create your own shortcut using GPP to achieve this.
shawn says
Agreed