Performance issue on WMR headset

Hello everyone,

we are facing a performance issue on our VR game that we do not fully understand. We are targetting the WMR headsets, and for now we are going through SteamVR to handle our headset.

Rendering of the game is ok while being in the editor and not using the headset. When we start our game in VR, we can see heavy jitters in the rendering.

We started digging with Unity profiler and found out that the framerate is like a seesaw, with the CPU usage graph showing a lot of Vsync. We understood that SteamVR/OpenVR does a vsync mechanism with a method called waitGetPoses(), and that the problem is to be found underneath.

Onto the rendering thread, we can see that the the call to GfxProcesscommands sometimes goes way beyond the standard time for a frame. By digging further, we found that we are waiting the end of a call to XR.DeviceSDK(), taking up to 16ms. Here is an example of profiling done in the editor :


Our camera renders in time, and then we wait for the XR.DeviceSDK to end up. Digging further, we dediced to bypass SteamVR and build our game as an Universal Windows App, to get rid of a layer in the pipeline. The situation got worse, but we were able to track one level deeper and see a call to WindowsMR.Present() :



Now we are a bit stuck in our investigations...

Did anyone encounter a similar issue ? What does unity do in the call to XR.DeviceSDK ? Could it be that we are doing something wrong in our game, and that it has an influence in the DeviceSDK stage ?

Any help appreciated ! Thanks.

 

I've been seeing poor performance when outputting to the WMR headset from within Unity. It sounds very similar to the above, so I will do some profiling to see if I see similar results.

I have noticed that if the game window is not visible while outputting to WMR that the frame rate on the headset bins and I see black bars\areas when moving my head.

 

I took a look in the profiler and I am seeing 8MS in V-sync regardless of the setting - I'm inclined to think that this is VR headsets and so that's normal.

I still have the issue of the frame rate binning +black bars, when the game Window is not open, but my juddering appears to come from a small near clip plane - I had it at 0.05, to allow for VR hands etc... but this causes even near geometry to appear ropey in the headset

 

Hi @jreiss

I am seeing exactly the same thing. I have regular spikes that I have traced to XR.DeviceSDK which is itself taking over 20ms. Have you had any more success with finding a cause?

I am using an Android HMD running Daydream (Lenovo Mirage Solo). As part of troubleshooting I upgraded to Unity 2018.3.12 but no joy.

I suspect it might be related to Blit Type and/or color space. In the same FrameEvents.XREndFrame call there is a call to XR.Blit and XR.WaitForGPU which reportedly finish immediately (perhaps they are async and the DeviceSDK is blocked until complete).

There seem to have been some issues with Blit type in recent versions of Unity which cause black screens. I was experiencing some of this but apparently in reverse to the bug reports. All documentation etc said Blit type must be Auto or Always when using Linear color space but I had to have it as Never or I would get a black screen. I have switch to Gamma color space to troubleshoot and tried various blit types but the same result.

 

@jreiss I have isolated the problem (for me) and can now eliminate the XR.DeviceSDK spike. However, I do not know if it will be the same problem for you. The problem comes from the Post Processing Layer attached to my camera. Even though I do not have any active post-processing volumes (I had deactivated all of these for testing) I still had the post processing layer on the camera. It was also set to no anti-aliasing and stop NaN propagation was off - so I thought it wouldn't be doing anything. When I disabled the post processing layer the XR.DeviceSDK spike went away.

I have been building this project for multiple platforms so will need to include conditional compilation or runtime checks to disable the post processing layer completely and not rely on just disabling the volumes.

Note, I also have MSAA and allow HDR enabled on the camera however I believe you cannot use hardware anti-aliasing (MSAA) with HDR so there might be some combination of turning off HDR/MSAA that will also eliminate the spike. I might do some more testing but I least now I know I can eliminate it and move forward.

Let me know if this helps you.

 

Hello everyone,

First of all thank you very much for your help on this thread !

Following all the answers, i've tried to conduct the investigations again. I can now confirm that the solution from @DarkVerse is a good lead; here is some FPS data from the profiler :

With the post-process layer on :


And with the Post-process layer off :


Quite an improvement We are still getting spikes in the FPS, is suppose it is because we also have other post process running on the camera. I now think that the issue is definitely located in the post-process running in our game.

Another investigation I ran is to swap the Windows Mixed Reality headset with a Vive headset; since our VR game rely on SteamVR, we can easliy swap for other hardware without touching the application.

The framerate goes like this :


Slower, but way more steadier framerate. Apparently, not all the devices seems to be affected by the issue.

As @DarkVerse describes, the issue happens on an android HMD. Does anybody encounter similar issues on other devices ? Is this a known issue in Unity ? Is there a way to pinpoint the issue ?

Thanks.

 

I am glad it helped @jreiss but there must be a more fundamental problem that can be triggered by different scenarios. I have just finished a day of optimising and trying to track things down and have finally got my frame rate to <13ms but the pesky XR.DeviceSDK is back. It is less frequent and less costly but it pushes the render time up to >22ms. I have post processing completely disabled so something else is triggering it. I am not in front of my machine now, and I am tired and have a wine in hand so that's all I can say for now. I will look into it more when I return from a break (in about a week).

 

I myself am having similar issues. Taking off post processing helped a lot, but I'm still getting often wildly fluctuating ms times from XR.DeviceSDK. I'm developing on the Oculus Quest. Would really like to know whats causing it.

 

Hi @CreepyLamppost do you discover anything about this? I am updating an old project and getting hit by excessive XR.DeviceSDK in some scenes and my previous "fixes" are not working. It only affects some scenes and in those scenes I am using a third party asset so I think it is something triggered by a shader provided by that asset.

 

I am getting terrible 100ms wait for XR as well. So I am not sure what is happening.

 

Hi @8bitgoose, I haven't fully tracked my issues down, and have been moved off to something else, but the last lead I was looking at was related to transparency in shaders. In particular, one shader was using a GrabPass, which is something I try to avoid as it is costly however a third-party asset is using it. Do you have any shaders using GrabPass or semi-transparent materials? If so, maybe look at them.

 

@DarkVerse Thanks for getting back to me. I disabled the SSAO of URP and it seemed to help. Was totally fine in a build so something weird is happening.