cancel
Showing results for 
Search instead for 
Did you mean: 

Oculus OpenXR runtime issue, prevents 90 Hz on PC.

BattleAxeVR
Level 4
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
Level 4
jb3y3ieng8bt.png

BattleAxeVR
Level 4
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
Level 4
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
Level 4
.

BattleAxeVR
Level 4
.

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
Level 4
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
Level 4
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.