cancel
Showing results for 
Search instead for 
Did you mean: 

Oculus OpenXR runtime issue, prevents 90 Hz on PC.

BattleAxeVR
Expert Protege
Hello forum and Oculus staff.

I opened a performance bug relating to Oculus' OpenXR runtime for Quest 2 on Nov 20th, which hasn't been fixed since Nov 20th and is threatening to stall the release of my game.

Can you please escalate this? The stall has been independently reproduced as of today by another user, in the hello_xr sample app and in their own code as well. It prevents 90 Hz operation via Link on PC.

Thank you for your time.
9 REPLIES 9

BattleAxeVR
Expert Protege
jb3y3ieng8bt.png

BattleAxeVR
Expert Protege
This is hello_vr just rendering a couple boxes and it can't manage 90 FPS. The stall is real. Can we please get a confirmation / receipt of acknowledgement here?

It's been independently corroborated in other software and therefore isn't a necesserily a bug in OpenXR's sample code, either.

What's weird is that Oculus OpenXR runtime works fine in Unreal, at full tilt. I don't know what to think any more.

BattleAxeVR
Expert Protege
If anyone says "hey, just use SteamVR's OpenXR runtime instead", well, no, that doesn't work properly on Quest 2 via Link either.

SteamVR's runtime doesn't have the 90 FPS / Hz stall bug, but you see a black image when it starts up, because it doesn't register the HMD tracking until / unless you manually reset the view. Then you see the image afterwards. This is 100% repro. This is a terrible workflow for development. Extremely frustrating and irritating.

Please fix the Oculus runtime so we don't have to depend on SteamVR's. Right now neither one works on Oculus headsets properly. I had similar problems on my Rift CV1 as well, though I haven't tested it recently.

qqzhur394nyy.png

BattleAxeVR
Expert Protege
.

BattleAxeVR
Expert Protege
.

johnkearney
Oculus Staff
Hi @BattleAxeVR,

Thanks for the report details.

I cannot replicate this issue locally, but we have had reports of similar issues on recent versions of Windows 10 (i.e. >= Version 2004). (I cannot replicate this issue as I'm testing locally with Windows 10 Version 1909.)

The issue in Windows 10 Version 2004 + is due to a change in underlying operating system timing APIs. We will release a fix for this (timing APIs in Version 2004) in release v27 of the Oculus PC Runtime.

It is possible to determine if this is the problem that you are seeing by calling `timeBeginPeriod(1)` in your game code before initializing OpenXR / loading the Oculus Runtime.

John

BattleAxeVR
Expert Protege
Thank you so much John.

That's very promising, now I can rest easy.

I'm glad I didn't waste too much time debugging this, but it's a bit curious how Unreal calling OpenXR runs at 90 FPS on the v25 runtime on my Quest 2 but hello_xr, a very basic sample, doesn't. Their timings / sequences of calls must be robust to Windows 10's changes (yes I am on the latest non-beta Win 10 build, actually on Win 10 Pro for Workstations in fact).

But whatever works! All's well that ends well. I

'll ping back to here to report (hopefully success) after the next release, and I'd like thank both you and Mr Carmack for looking into this.

Cheers.

johnkearney
Oculus Staff

... it's a bit curious how Unreal calling OpenXR runs at 90 FPS on the v25 runtime on my Quest 2 but hello_xr, a very basic sample, doesn't.


I expect that it is likely that Unreal needs to call `timeBeginPeriod` for the purposes of it's own timing and therefore using Oculus runtime in Unreal will not hit this issue.

BattleAxeVR
Expert Protege
Unreal calls it in WindowsPlatformMisc.cpp (587)

And in a handful of other places too (audio, etc). 

I tried it and it fixed my issue, both in hello_xr and more importantly, my own engine. 90 FPS in Link, finally.

I'm going to leave it in there. Thanks again John.