OpenXR long Wait times causing lag

As you can see, I’m getting long WaitFrame timers called by the OpenXR plugin. This is Trace data captured on the Quest 2.

Any ideas about what this could mean or how to fix it?

better screenshot.


found the code thats causing it, but don’t know what else to do

This looks like normal behavior. The xrWaitFrame function synchronizes the framerate with the frame timing of the VR hardware. If the application isn’t submitting and rendering the frame in time, it will block until the next frame. It also throttles the framerate down after several missed frames, like you can see on the first image where the baseline goes from 45 fps to 30 fps.

Not sure, but it seems like you might be CPU bound by the render thread.

2 Likes

i just don’t understand

heres some frame times for a fast frame.

heres some frame times for a slow frame.

they’re basically the same apart from the long wait for task calls in both the game and render thread

Edit: I took out the landscape foliage, trees, and it’s better but still not amazing. it’s a small level with not much going on, so I figure the FPS should be good.

The runtime will start to throttle the framerate back for longer periods when it sees that the application is consistently missing frames, so you get those big red chunks of 20 fps, even though the actual frame time varies inside it.

It’s hard to tell exactly how the frame timing varies without going through every frame, since the Unreal profiler includes the waiting time. I’m not sure what profiling tools are available for Oculus, but the runtime should have some sort of built-in ones for graphing the actual frame times as the runtime sees it.

1 Like

@xXbollerXx Did you end up figuring this out?

no, sorry.

Im seeing the same issue on my end. I have optimized the living hell out of my app and still seeing these long WaitTimes.

I was seeing very good performance in ue 5.2, but since updating to 5.5 its been very slow like this. Not sure what changed.

If it’s throttling to a flat framerate as in the images above, look at what is happening in the frames just before it triggers. The runtime will usually keep throttling for a while before going back to the faster framerate even when you are consistently making it.

Okay so my issue was that there was some settings missing that didn’t get transfered over from our previous engine upgrade. Not sure exactly which setting made the improvement, but:

Inside DefaultDeviceProfiles.ini:

I added :

[Oculus_Quest DeviceProfile]
DeviceType=Android
BaseProfileName=Android_Mid
bIsVisibleForAssets=False
+CVars=r.Mobile.SoundwaveTargetFrequency=2000
+CVars=vr.VRS.HMDFixedFoveationDynamic=1
+CVars=r.Android.DisableVulkanSupport=0
+CVars=r.Android.DisableOrientationPolling=1
+CVars=r.Vulkan.AllowFragmentShadingRate=0
+CVars=fx.NiagaraAllowGPUParticles=1
+CVars=FX.AllowGPUSorting=1

then in DefaultEngine.ini added:

[/Script/OculusXRHMD.OculusXRHMDRuntimeSettings]
+SupportedDevices=Quest2
+SupportedDevices=QuestPro
+SupportedDevices=Quest3S
+SupportedDevices=Quest3
FoveatedRenderingLevel=Low
ProcessorFavor=FavorCPU

some of those settings may not be applicable to you, or the root issue, but I’m just adding all so I don’t miss any. My frame rate is back to normal now