by Magnar Johnsen
Special Note: NVIDIA GRID recently announced a range of enhancements for monitoring virtualized GPUs. These are already being adopted by many popular commercial monitoring products such as eG Innovation, Lakeside SysTrack and Liquidware Labs, among others. With an open API/SDK, NVIDIA encourages ISVs, customers and end users to build or incorporate GPU monitoring information into their tools and products. NVIDIA GRID Community Advisor Magnar Johnsen has also been working on tools, providing our SDK and development team with feedback on how we can enhance our monitoring and management functionality long-term. Magnar agreed to write about his tools and release them to the community for general benefit.
Humans have always used tools to extend our capabilities. Remote graphics is one such powerful tool that enables people to work smarter. But the success of using such a tool depends on implementing it in the right way. Over my years working with remote graphics implementations, I’ve learned that you need to be able to see what’s happening to understand how to size and optimize these solutions. Sometimes you don’t find the tools that you need (or at a price you like), so that’s when I make my own tools. In this post, I will tell a little about two such tools that I’ve developed and shared with the community over the last couple of years.
This tool is displayed as an overlay to applications so you can see the numbers at the same time as the application. What I wanted was to see how many frames per second were delivered to the endpoint when you run a graphical workload in a Citrix session. I was able to extract this information along with some other GPU and Citrix protocol related data and display on the top of the screen the same way as FRAPS. Now if you run both tools, you can see the difference in what the GPU produces and what is delivered to the endpoint.
In version 2 of GPUPerf, I added support for Teradici PCoIP and Microsoft Remote FX. Now it was possible for me to actually compare different protocols and get some metrics on how many FPS are delivered to the endpoint, what bandwidth is required, and the CPU and GPU load of the virtual machines.
With NVIDIA GRID vGPU, it was not possible to get the GPU utilization per VM. After the August 2016 release of NVIDIA GRID drivers, a couple of new things were introduced. vGPU monitoring was now possible and with additional information about the NVENC engine. NVENC is the NVIDIA hardware h.264 encoder that modern remoting protocols use for encoding H.264. Now it was time for me to add this data to GPUPerf. Luckily, it was quite easy to implement these new monitoring counters. So I’m very proud to be able to share version 3 of GPUPerf with the community. In version 3, you can now monitor in real-time vGPU utilization and NVENC utilization. In addition, I’ve added support for two new protocols, Citrix Framehawk, and VMware Blast. I’ve also extracted how much CPU is utilized in the protocol encoding process. This reveals how much CPU you can save by enabling hardware h.264 encoding on the server.
In this video you can see how GPUPerf3 reveals information on server GPU and CPU usage when running a Youtube video on XenDesktop. This video shows how Autodesk 3DStudio max is using the GPU and CPU on XenDesktop.
You can download GPUPerf3 for free here.
This tool is made to help you select the best vGPU profile based on GPU utilization of existing workstations. You run the tool for a while on your workstations and it records your GPU utilization and framebuffer utilization. It also looks at your screen resolution and number of monitors. Based on this information and feedback and advice from Erik Bohnhorst at NVIDIA, I have developed algorithms that convert the peak framebuffer utilization to a vGPU profile. I also look at the capacity of your existing GPU and try to convert this to the capacity of the NVIDIA GRID cards. With this information you can easily see what kind of hardware you will need to virtualize your workstations and how it will scale.
This tool is still under development but you can download a beta version here. I actively welcome feedback.
This is a sample workload, and you can quickly see that this workload could scale up to 128 users with an M10 card. You can also find out which applications are using DirectX, OpenGL, OpenCL, and CUDA.
In this video you can see how Autodesk 3DStudio requires a minimum 2GB profile on Windows 10, and that the K1 GPU is not recommended, because it isn’t powerful enough.
I’m sharing my tools with the community to be able to learn and share knowledge and experience with others. I’ve learned a lot by developing these tools but even more by sharing it. Since I’ve been invited to join the NVIDIA GRID Community Advisor program, I have been able to get a lot of information and help to develop my tools, test them in labs and get feedback from top experts in NVIDIA and the community.
Magnar (as a third party) supplies his tool as a community project and as such NVIDIA does not test or verify them and cannot officially endorse their use. Users should use their own judgment as to when to utilize this functionality.
To learn more about the NGCA and how you can become an advisor, click here.
EUC and remote graphics specialist and owner, Firstpoint Bergen AS
Magnar is a EUC solution specialist, blogger, speaker, and community tool developer with 15+ years experience in End User Computing. Based in Bergen, Norway, he has worked with Citrix, Microsoft and VMware products since 1999 and with NVIDIA products since 2012. Magnar has a passion for technology, computer visualization, and virtual reality, as well as experience in 3D modeling, graphic manipulation, and video effects. He has assessed, designed, implemented, and supported many virtual graphics solutions based on NVIDIA technology for small to large companies in the oil and gas industry in Norway. Magnar shares his knowledge, tools and experience on his blog, https://www.virtualexperience.no, and speaks at numerous industry conferences including Citrix Synergy, Briforum and Citrix User Group.