I don’t know…..I’m not psychic ;-)! It’s a question that occasionally comes up so I’ve put together a trouble-shooting guide, available here:
- CTX202149 – Known Issues or Configuration Reasons: OpenGL/DirectX/GPU Acceleration Not Used
- Links to tools to identify the issue
- Known common configuration errors
- Known issues with GPU drivers
- Information on applications and Operating Systems that turn GPU-acceleration off by default.
You should always consult the CTX article as it is likely I will add to it in the future, but here is what I published today! Please do add any other issues you find to this blog comments and also let me know if you came across one of the issues (and which one), so I can work out whether writing lots of CTX articles is indeed a good use of my time! 😀
Known Issues or Configuration Reasons: OpenGL/DirectX/GPU acceleration is not being used
Browsers are often an integral part of the operating system and as such aware they are virtualised. As such we would recommend those finding issues within a browser also test with a standalone benchmark application to verify if it is a configuration issue with GPU/OpenGL usage in general or whether it is specific to that browser. It is also helpful if users check whether the issue affects DX9, DX11 and OpenGL separately as the implementations differ.
- CTX202010 – Internet Explorer is Not GPU-accelerated When Virtualized on XenServer 6.2
- CTX202065 – Mozilla Firefox Blocks GPU Acceleration for WebGL with XenApp on Windows 2012 R2/2008 R2
- CTX202066 – GPU-accelerated OpenGL on Amazon Web Services (AWS G2 instances) with NVIDIA GRID K520/K340 No Longer Works
- CTX202084 – Internet Explorer 9: Hardware Acceleration Does Not Work in Some Virtualization Environments (including vSphere/ESXi)
- CTX202106 – Publishing Chrome Browser for XenApp – so that GPU acceleration is enabled
Known Dependency for Internet Explorer: CPU must support SLAT (Second Level Address Translation)
Internet Explorer 9 and up will only be able to use a supported GPU for hardware-accelerated rendering if Service Pack 1 (for 2008 R2) is installed, and the processor supports SLAT. This is documented in this article from Microsoft: https://support.microsoft.com/en-us/kb/2528233.
Most newer servers support SLAT but customers using older hardware should check they have SLAT support.
Here are some links that might be useful in finding your CPU SLAT support:
- http://www.windowsitpro.com/article/virtualization2/Q-How-can-I-tell-if-my-Windows-Server-2008-R2-Hyper-V-implementation-is-using-Second-Level-Address-Translation-SLAT-.aspxSome other links which might be helpful in understanding SLAT:
Known Common Configuration Issue: Under RDP/RDS for XenApp on Windows Server OSs (Win 2008 R2, Win 2012 R2 etc) are configured to disable GPU acceleration
Remote Desktop Services (RDS) sessions on the RD Session Host server by default use the Microsoft Basic Render Driver and therefore do not use the GPU. This prevents 2D DirectX applications (such as MS office apps) from using GPU resources for rendering which can sometimes be more efficiently performed in software. To run 3D applications that use DirectX in RDS sessions, it is recommended that they are run on a dedicated server where 2D apps are not likely to compete for GPU resources. For this server, the default behaviour should be changed to use the GPU in RDS sessions by enabling the enable the “Use the hardware default graphics adapter for all Remote Desktop Services sessions” setting via group policy.
Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment.
Note: There are some comments on this MS blog that fill in some details.
Known Common Configuration Issue: Under RDP/RDS for XenApp on Windows Server OSs (Win 2008 R2, Win 2012 R2 etc) are WPF applications such as Autodesk’s have to be explicitly enabled
On both Windows Server 2008 R2 and Windows Server 2012 R2:
To enable WPF applications (such as Autodesks’) to render using the server’s GPU, create in the registry of the server running Windows Server OS sessions the following settings:
- [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\ Multiple Monitor Hook] ” EnableWPFHook” =dword:00000001
- [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\ Multiple Monitor Hook] ” EnableWPFHook” =dword:00000001
The use of these registry keys is fully supported by Citrix, however customers should ensure care when editing them and Citrix cannot bear responsibility for problems arising from incorrect editing of registry keys (as below).
Known Monitoring Limitations: XenCenter Metrics show 0 for GPU-passthrough
Users should be aware of limitations in monitoring insight when using NVIDIA GRID technologies such as vGPU and GPU pass-through: https://virtuallyvisual.wordpress.com/2015/07/27/limitations-in-monitoring-shared-nvidia-gpu-technologies/ . GPU pass-through can only be monitored from within a guest and metrics with in XenCenter or from XenServer will be shown as 0.
Caution! Using Registry Editor incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
References / Useful links:
- Tools for monitoring and investigating GPU usage
- Configuring Autodesk for XenApp GPU usage: http://blogs.citrix.com/2014/05/28/configuring-virtualised-autodesk-and-similar-applications-including-xenapp-gpu-sharing-and-tools-for-sanity-checking-directxopengl-usage/
- Third-party blog outlining issues with various browsers and NVIDIA GRID GPU-acceleration: http://www.barryschiffer.com/citrix-hdx-3d-pro-and-nvidia-grid-browser-experience/