Episode 008 of the Unexplored Territory podcast is available! This week we spoke with Matt Coppinger about Virtual Reality and VMware Workspace ONE XR HUB, which is the enabler for VR adoption in the enterprise. Listen to it via Spotify (https://spoti.fi/3fSUrAM), Apple (https://apple.co/3FUOLkq), or anywhere else you get your podcast!
nvidia
Unexplored Territory #005: AI Enterprise, DPUs, and NVIDIA Launchpad with Luke Wignall
Episode 005 is out! This time we talk to Luke Wignall, who is the Director of Technical Product Marketing at NVIDIA. We talk about some of the announcements made during the NVIDIA GTC Conference. Luke discusses NVIDIA Launchpad, AI Enterprise, and of course, we touch on DPUs aka SmartNICs. A great conversation with A LOT of information to digest. Enjoy the episode, and if you haven’t done so yet, make sure to subscribe! You can also listen via your podcast apps of course for Apple: https://apple.co/3lYZGCF, Google: https://bit.ly/3oQVarH, Spotify: https://spoti.fi/3INgN3R.
Whitepaper: Running Augmented and Virtual Reality Applications on VMware vSphere using NVIDIA CloudXR
As many of you know by now, I worked on this project with the VXR team at VMware to try to run Augmented and Virtual Reality Applications on VMware vSphere. The white paper demonstrates that, using VMware vSphere backed by NVIDIA Virtual GPU technology, AR/VR applications can be run on a Windows 10 virtual machine with an NVIDIA vGPU, and streamed to a standalone AR/VR device, such as the Oculus Quest or Vive Focus Plus, using NVIDIA’s CloudXR protocol. It was a very interesting project as we had some real challenges I did not expect. I am not going to reveal the outcome of the project and our findings, you will need to read the white paper for that, it will also give you a good understanding of the use cases around these technologies in my opinion. One thing I can reveal right here though is that these workloads are typically graphic intense. I want to share with you one image which in my opinion explains why this is:
Traditional apps/workloads usually run on a single monitor with a frame rate of 30 frames per second. VR applications are presented in a VR headset. A VR headset has a display for both eyes, that doubles the number of megapixels per second immediately, but these displays also expect 72 frames per second or more typically. This is to avoid motion sickness. All of this is described in-depth in the white paper, of course including our findings around GPU utilization when running VR/AR applications using NVIDIA CloudXR, NVIDIA and VMware vGPU on top of VMware vSphere. I hope you enjoy reading the paper as much as I enjoyed the project!
Go here to sign up for the white paper: https://pathfinder.vmware.com/activity/projectvxr
Last day of my Take 3 with the @ProjectVXR team!
Today is the last day of my Take 3 with the Project VXR team. Ridiculous how fast these 3 months went. It seems like only yesterday that I posted I was going to start this journey of learning more about the world of Spatial Computing and Remote Rendering of VR in particular. If I say so myself, I feel that over the past 3 months I managed to accomplish quite a lot. The last three months I spend figuring out how to virtualize a Virtual Reality application and how to stream the application to a head-mounted display. I tested different solutions in this space, some of which I discussed on my blog in the past months, and I was surprised how smooth it worked, to be honest. If you are interested in this space, my recommendation would be to look into NVIDIA CloudXR in combination with vSphere 6.7 U3 and NVIDIA vGPU technology.
I can’t share all the details just yet, I wrote a white paper, which now needs to go through reviews and copy editing, and hopefully, it will be published soon. I will, however, discuss some of my findings and my experience during some of the upcoming VMUGs I will be presenting at. Hopefully, people will enjoy it and appreciate it.
One thing I would like to do is thank a few people who helped me tremendously in the past few months. First of all, of course, the folks on the Project VXR team, they gave me all the pointers/hints/tips I needed and shared a wealth of knowledge on the topic of spatial computing. I also like to thank Grid Factory, Ben in particular, for the many discussions, emails etc that we had. Of course also NVIDIA for the discussions and help around the lab equipment. Last but not least, I want to thank the VMware OCTO team focussing on Dell Technologies for providing me with a Dell Precision Workstation, and shipping it out literally within a day or two. Much appreciated everyone!
Now it is time to get back to reality.
NVIDIA rendering issues? Look at the stats!
I’ve been down in the lab for the last week doing performance testing with virtual reality workloads and streaming these over wifi to an Oculus Quest headset. In order to render the graphics remotely, we leveraged NVIDIA GPU technology (RTX 8000 in my case here in the lab). We have been getting very impressive results, but of course at some point hit a bottleneck. We tried to figure out which part of the stack was causing the problem and started looking at the various NVIDIA stats through nvidia-smi. We figured the bottleneck would be GPU, so we looked at things like GPU utilization, FPS etc. Funny enough this wasn’t really showing a problem.
We then started looking at different angles, and there are two useful commands I would like to share. I am sure the GPU experts will be aware of these, but for those who don’t consider themselves an expert (like myself) it is good to know where to find the right stats. While whiteboarding the solution and the different part of the stacks we realized that GPU utilization wasn’t the problem, neither was the frame buffer size. But somehow we did see FPS (frames per second) drop and we did see encoder latency go up.
First I wanted to understand how many encoding sessions there were actively running. This is very easy to find out by using the following command. The screenshot below shows the output of it.
nvidia-smi encodersessions
As you can see, this shows 3 encoding sessions. One H.264 session and two H.265 sessions. Now note that we have 1 headset connected at this point, but it leads to three sessions. Why? Well, we need a VM to run the application, and the headset has two displays. Which results in three sessions. We can, however, disable the Horizon session using the encoder, that would save some resources, I tested that but the savings were minimal.
I can, of course, also look a bit closer at the encoder utilization. I used the following command for that. Note that I filter for the device I want to inspect which is the “-i <identifier>” part of the below command.
nvidia-smi dmon -i 00000000:3B:00.0
The above command provides the following output, the “enc” column is what was important to me, as that shows the utilization of the encoder. Which with the above 3 sessions was hitting 40% utilization roughly as shown below.
How did I solve the problem of the encoder bottleneck in the end? Well I didn’t, the only way around that is by having a good understanding of your workload and proper capacity planning. Do I need an NVIDIA RTX 6000 or 8000? Or is there a different card with more encoding power like the V100 that makes more sense? Figuring out the cost, performance and the trade-off here is key.
Two more weeks until the end of my Take 3 experience, and what a ride it has been. If you work for VMware and have been with the company for 5 years… Consider doing a Take 3, it is just awesome!