Validating WPF application acceleration with NVIDIA GRID

Cloud-DUo WPF checker for NVIDIA GRID

Last week, a customer of mine asked me to take a look at an issue where their in-house WPF application was not using hardware acceleration with NVIDIA GRID.
The outcome of the troubleshooting gave me a lot of new insights and I was able to resolve and validate WPF related issues.

First, let me give some background information involving the environment. The customer was running XenApp 7.15 CU2 LTSR XenApp (Server 2016 Desktop) on Cisco UCS rack servers.
all servers were configured with an M10-8A profile and the GRID driver version was vSphere GRID 7.1

Initial analysis

After an initial validation of the driver and making sure applications like Google Chrome, Microsoft Office were indeed using hardware acceleration.
Validating GRID driver functionality
I started validating the WPF application. The customer development team integrated a default “hardware acceleration check” function found on the Microsoft website.

Based on the Microsoft Graphics rendering Tiers , Thibaut Noben a colleague of mine and I wrote a similar application that checks if software or hardware acceleration is used by the WPF application. The application will prompt a value between 0 and 2.

  • Rendering Tier 0 No graphics hardware acceleration. All graphics features use software acceleration. The DirectX version level is less than version 9.0.
  • Rendering Tier 1 Some graphics features use graphics hardware acceleration. The DirectX version level is greater than or equal to version 9.0.
  • Rendering Tier 2 Most graphics features use graphics hardware acceleration. The DirectX version level is greater than or equal to version 9.0.

You can download the application here on our Cloud-Duo Github. This application was made by my colleague: Thibaut Noben.
CloudDuo WPF checker no acceleration
The tool will give you a global indication if all WPF application uses hardware acceleration, this can be NVIDIA GRID or other hardware/software acceleration.

An alternative and second method, to validate if the application itself is using hardware acceleration is the Microsoft WPF Performance Suite.
In the suite, you can use a tool called “Perforator”, which analyzes WPF rendering behavior.
Microsoft WPF performance suite Perforator process

Select the “Perforator” and load the WPF application process into the profiling tool. This will automatically detect the overall Frame rate, video memory usage,… .
Perforator WPF application usage

As you can see the application itself was not really using any video buffer. To confirm that no GRID was used, select “Draw software rendering with purple tint”.
This will as it says, give all areas of the WPF application a purple tint that is using software rendering. In the case of the customer’s application, this was the entire application.
software rendering WPF application
Due to NDA, I was only allowed to take a screenshot of a blank area of the application. But you will get the idea!

Solving the problem – Citrix side

After concluding that software acceleration is used, I started finding a solution to the issue.

The first thing was validating if the Citrix VDA agent was indeed using the WPF application hook. This is enabled by setting the following registry key “EnableWPFhook” by setting this as a DWORD with value 1.
Citrix VDA enableWPFhook

As this was not the solution, I started to search the Citrix forums for any clue on what could be the root cause. I stumbled on the following Citrix forum post.
On page 2, hnoeman608 mentioned that the AppInit_DLLs where empty. As the WPFhook was located in the AppInit_DLLs registry hive, I had high hopes this would solve the issue.

This both for the system32 and syswow64 registry key:

Key Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
Entry Name: AppInit_DLLs
Entry Type: String
Value: mfaphook64.dll
Key Location: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows
Entry Name: AppInit_DLLs
Entry Type: String
Value: mfaphook.dll

After changing these registry settings, we rebooted the server to make sure everything was load correctly.
But nothing… we still had the same issue. Frustrating! But I felt I was missing some critical thing.

Solving the problem – NVIDIA side

After solving the Citrix registry, I was convinced something was still wrong with the NVIDIA driver installation and the interoperability with the Citrix VDA.
As the primary NVIDIA GRID product specialist at my current employer, I have gained a lot of experience in troubleshooting NVIDIA GRID related issues.

So I wanted to make sure the installation of the driver was done in the correct order. What I noticed when I checked the installation order in the software deployment tool., was that the Citrix VDA was installed before the NVIDIA Driver.

This is not the correct order, as it should be following to make sure NVIDIA GRID is enabled and will be used.

  1. NVIDIA driver
  2. VDA
  3. Other applications

To validate the installation of the driver and the interoperability with the VDA, you can use the NVFBCEnable.exe from the NVIDIA Capture SDK.
This can be simply downloaded from the NVIDIA developers website, signing up is completely free. https://developer.nvidia.com/

After downloading and installing the SDK onto one of the XenApp Servers. Open a command prompt from the following directory and run following command: nvfbcenable.exe -checkstatus
NVFBCenabled is disabled

Jackpot! The NVIDIA FrameBuffer cache has not correctly been enabled, meaning CUDA, OpenGL and WPF application will not correctly use hardware acceleration.

To enable, the FBC, we need to run following command nvfbcenable.exe -enable -noreset

After rebooting, the same -checkstatus command will give the following output:
NVFBCenable is now enabled

Validating WPF application

When we did the same validation with Microsoft Perforator for the WPF application. We got an entirely different result.
This is both with the Citrix changes and the NVIDIA changes, I validated with and without the AppInit_DLLs registry keys.
Perforator is hardware accelerated

We can see that indeed the application is using video memory, as well as the frame rate higher than before. With the same “Draw software rendering with a purple tint” option selected, we now saw that no areas where purple. When running the WPF checker tool we wrote the output should be something like this. The rendering Tier value is now indeed 2!

Conclusion

By implementing both the Citrix and NVIDIA fixes, we successfully enabled the WPF application hardware acceleration on NVIDIA GRID for my customer.
We have shown multiple ways of validating WPF rendering functionality and created a Cloud-Duo WPF checker tool that you can use in your environment.

Horizon:
The same WPF checker can be used in a Horizon environment. But WPF offloading is not enabled by default.
The necessary configuration to enable WPF offloading on HorizonApps en Horizon VDI will be discussed in part 2 of this blog post series.

More GRID posts: Nvidia GRID Troubleshooting – basics

Change Log:
26/06 – added validation of the installation order.

2 comments on “Validating WPF application acceleration with NVIDIA GRID

  1. Hi,
    you should mention which VDA installer you used. 7.15 LTSR is “special” as there is a difference between standard VDA and HDX3D Pro VDA. I assume you installed the standard VDA which will indeed lead to the symptom that you won’t have NVFBC present.

    1. Hi Simon,
      Yes, As the customer was using server 2016 RDSH (server OS), we were indeed using the standard mode.
      Also when I checked the software deployment tool that was used for deploying the golden image. I noticed the NVIDIA drivers were installed after the Citrix VDA.
      What I see to have forgotten to mention in the blog (I will update it), so the NVFBC was not enabled.
      After enabling it and making sure the WPF hooks were set, the WPF application was using hardware rendering and we had a happy customer. 🙂
      Regards,

Leave a Reply

Your email address will not be published.