I am using OpenXR to integrate hand controls into an already existing game engine (an engine that already has a framerate controller). My application calls update to my OpenXR input system, and then updates other game engine systems, and finally waits for for appropriate frame time. In its update, my OpenXR input system calls XrWaitFrame, then XrBeginFrame, then XrEndFrame. So my use of OpenXR completely skips any rendering, but it seems that XrWaitFrame is still trying to wait for frame timing, which is gumming up the total framerate down to 45 (from our target 60).
I think the issue is that I am calling all of these in quick succession as a part of the input update, but that is kind of a constraint of my setup, does anyone know if there is a way to skip calling wait, or trick it into returning immediately?
Just mentioning that even if you did want OpenXR to control your frame rate, it would synchronize you to the frame rate the runtime deems appropriate for the connected VR headset, not the framerate of the monitor you want to show your non-VR app on.
By design, xrWaitFrame throttles your application down to the refresh rate of the headset in the ideal case, or to a lower framerate if the runtime sees fit to do so. If you are familiar with OpenVR, it is similar to WaitGetPoses in that respect.
In OpenXR xrWaitFrame and xrSyncActions are different things though. I’m not sure if this is allowed right now but you might try not calling any of the xr*Frame functions and only call xrSyncActions. You will need a timestamp of when you predict your next frame to be shown for this and on runtimes that support the XR_KHR_win32_convert_performance_counter_time / XR_KHR_convert_timespec_time extensions, you may convert a timestamp in your system time to OpenXR time with those.
If runtimes do not like it when you never call xrWaitFrame, then your only real option would be to put the OpenXR frameloop into a thread and otherwise ignore what it does.
It sounds like what you really want aligns with XR_MND_headless though Monado is currently the only OpenXR runtime that has implemented this extension.
Thanks for the suggestion! I tried my hand at putting it on its own thread once but with no luck yet, so I will definitely give the XrSyncActions route a try… If not, back to the threading docs for me! I’ll try to remember to update here if it works…
And yup, you are correct, I wanted headless mode reeal bad haha. It was in the base specification in 0.9, I was sad to see it missing in 1.0
Its absence was mostly due to the fact that the interactions with things like the frame loop weren’t well specified, and I couldn’t really articulate well use cases that other runtimes might want to support besides “I want to be able to view the tracker data without caring about graphics APIs”. If you can elaborate on your use case a bit, it might help. You’re also welcome to help revise the current vendor extension to make it more complete. Some ideas included having a separate form factor (so you could have a runtime with no headset, just tracking), etc. The current extension basically just formalizes “what monado did” for the old 0.90 spec’s extension at the time.