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?
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?
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.
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.
@xXbollerXx Did you end up figuring this out?
no, sorry.