Performance issue with OVRPlugin using OpenXR backend

[chcheng]

Hello, our game is using Unity 2020.3.32f1 and Oculus Integration v39.0.0. We found in profiler that with OpenXR backend, OVRManager takes about 2ms CPU every frame on a Quest 1 device, while it only takes about 0.32ms if we switch back to the legacy OVRPlugin with LibOVR and VRAPI backends.

(The profiler data were taken using a new project with only Oculus Integration 39.0 added, and with the sample scene MRC in Oculus/VR/Scenes)

OVRPlugin with OpenXR backend Legacy OVRPlugin with LibOVR and VRAPI backends

With deep profiling on, we found that it is from OVRP_1_16_0.ovrp_GetControllerState4(). We also found that if we remove the battery in 1 or both Oculus Touch controllers, the time drops (with 1 battery removed, it drops to around half and with both removed, it drops to near 0ms, but of course we can no longer play without controllers).

OpenXR backend deep profiling

As a result of this, we can hardly switch to the OpenXR backend due to the FPS requirement in Quest 1.

Anyone knows if I am missing something or is it a problem with the plugin itself? Thank you.

[baroquedub]

This kind of in depth post shows how much we need a proper bug tracker for the Oculus SDKs. Very few Meta engineers ever seem to post here, but this kind of performance issue really needs an answer

[ZorakMantis2]

I know your post is older, but have you had any success working around any of this?  In my use-case, OpenGL+VRAPI is enough fastern than Vulkan+OpenXR that I can't consider using the newer libraries yet.  Super frustrating for us as we also desparately need the improved depth precision of Vulkan.