Yellow Bricks

by Duncan Epping

vxr

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

Disabling the frame rate limiter for your vGPU

· ·

I have been testing with Virtual Reality apps within a VM for the past few days and I am leveraging NVIDIA vGPU technology on vSphere 6.7 U3. I was running into some undesired behavior and was pointed to the fact that this could be due to the frame rate being limited by default (Thank Ben!). I first checked the head-mounted display to see at what kind of frame rate it was running, by leveraging “adbLink” (for Mac) and the logcat command I could see the current frame rate hovering between 55-60. For virtual reality apps that leads to problems when moving your head from left to right as you will see black screens. For the Quest, for those wanting to play around with it as well, I used the following command to list the current frame rate for the NVIDIA CloudXR application (note that this is specific to this app) and “-s” filters for the keyword “VrApi”:

logcat -s VrApi

The result will be a full string, but the important bit is the following:

FPS=72,Prd=32ms,Tear=0,Early=0

I was digging through the NVIDIA documentation and it mentioned that if you used the Best Effort scheduler a frame rate limit would be applied. I wanted to test with the different schedulers anyway so I switched over to the Equal Share scheduler, which solved the problems listed above as it indeed disabled the frame rate limit. I could see the frame rate going up between 70 and 72. Of course, I also wanted to validate the “best effort” scheduler with frame rate limit disabled, I did this by adding an advanced setting to the VM:

pciPassthru0.cfg.frame_rate_limiter=0

This also resulted in a better experience, and again the frame rate going up to 70-72.

Map head-mounted display to AMD ReLive VR instance

· ·

Warning before the post, I don’t have a good solution for you unfortunately at this time. One of the things I have been testing during my Take 3 is to have multiple head-mounted displays (VR goggles) on the same network connecting to multiple VMs. With ALVR this is pretty easy to do as the ALVR interface allows you to select the head-mounted display (HMD) you want to connect with as shown below. Very easy to use, and it allows you to always connect to the same head-mounted display as there’s an “auto-reconnect” option as well. (Which wasn’t always consistently reconnecting in my testing, unfortunately.)

I figured AMD would offer something similar, and it appears they do. After installing the AMD Radeon Pro software I couldn’t find the option that was described on Github. In the Radeon Pro software there’s no “devices” tab. Then I noticed that this is, unfortunately, only available for Adrenalin 2020, which is different then Radeon Pro software. So it seems that this functionality hasn’t been ported yet.

Can you get around it? Well, of course, you can have multiple VMs with ReLive VR instances running and have HMD’s connect to them, but this would be completely random. During normal behavior this wouldn’t be a problem, but when troubleshooting this would make life a lot more challenging. The way to get around it today would be to create different (wifi) networks and separate each pair (VM+ReLive VR instance and HMD) logically. This would work okay with a few head-mounted displays, but of course would not scale when you have more than a few. Let’s hope that AMD solves this problem soon. I reached out to AMD for a comment, they mentioned that you can use the Adenalin 2020 driver as well for the Pro cards, and that the feature for the Pro card is coming soon.

Can’t enable AMD ReLive VR during install of Radeon Pro Software?

· ·

Yesterday I bumped into an issue where I wanted to enable AMD ReLive VR but the option didn’t show in the configuration window strangely enough. I remembered that the first time I installed the Radeon Pro Software for Enterprise I had an option to enable AMD ReLive VR during the process, but I couldn’t recall seeing the option this time during the install. I simply reinstalled Radeon Pro assuming the option would pop up but it didn’t. It seems that this was caused by the fact that there were already AMD drivers installed, a bit strange as all other AMD Radeon Pro components can be selected and installed when there’s a driver present, but ReLive simply won’t show up as an option.

So I used the AMD provided tools to completely uninstall all AMD Radeon related software. When you do this and you reboot the VM you will be presented the following screen at the end of the install of the Radeon Pro software, this then allows you to install ReLive VR, which you can then configure and enable through the settings window as also shown below.

AMD Radeon settings window transparent in a VM?

· ·

I have been playing with VR technology for the past month. The last couple of weeks my focus has been to install/configure a VM which streams the VR app over wifi to a headset. I ran into a problem with ALVR last week as documented here, but I also ran into an issue with the AMD Radeon software when I wanted to use the AMD tools to stream a VR app. When you install the AMD Radeon software within a VM and want to configure the (passthrough) graphics card or ReLive VR the Radeon configuration window shows up transparent, it looks as below. Which means you can’t configure it, you can’t enable things like ReLive VR.

The only way to get the window to show up normal is to remove the VMware SVGA device using Device Manager. Simply completely remove it and restart the VM and the problem is solved. If you have svga.present set to false you will need to click “view hidden devices” in Device Manager first before you can remove the installed software/driver by the way. When rebooted it will look normal again and it will allow you to enable and configure ReLive VR, or any other options you need to configure of course.