Porting C++ Native PC SDK with OpenGL to OpenXR Guidance Request
Need to port unpublished Oculus Rift C++ OculusSDK, Platform SDK, and Avatar SDK (w. OpenGL) application that is working Ok to OpenXR due to deprecation of native SDK, where might I find guidance / documentation / examples on how to do this?
Updating an app from previous (0.8) Rift libraries to current (1.17) libraries causes screen flicker
I've updated from 0.8 to 1.17, rewritten for the texture swap chain, etc.. but my application now flickers constantly while running. Any ideas what might cause this? Hardware is a GEForce 1060 w/ 6 Gb, i7-6700 @ 2.6 Ghz, 16 Gb RAM.. no reason there should be any drop in framerates or anything.
Bubbles in the GPU queue at the start because of ovr_submitFrame
https://developer3.oculus.com/documentation/pcsdk/latest/concepts/dg-hud/ says: Compositor Frame-rate The rate of the final composition; this is independent of the client application rendering rate. Because the compositor is always locked to V-Sync, this value will never exceed the native HMD refresh rate. But, if the compositor fails to finish new frames on time, it can drop below the native refresh rate. The native engine I'm working on calls `ovr_submitFrame` from the render thread, and is currently designed such that the next frames work (sim + render prep + submit) starts only after `present` is called on the render thread. GPUView tells me that `libOVR*.dll` waits on a sync object, resulting in the CPU doing literally nothing during a 3-4 ms period. This happens every frame (App CPU frame time is generally 5-7 ms, App GPU frame time is 10-13 ms), and results in bubbles in the GPU Queue at the start of the next frame. When the render thread does resume execution, the stack in GPUView shows a bunch of kernel/os stuff for ~1.5 ms before `libOVR*.dll` shows up in the stack and my engine only then gets back control flow. I can't quite explain what that's about. In the pic below, notice: (a) the CPU render thread being idle because of a sync object in libOVR*.dll (b) small bubbles in the GPU queue at the start for the next frame as a result My questions are: (1) Does `ovr_submitFrame` return only after the HMD's vblank? If so, why doesn't the SDK let the app query time to vblank and throttle itself accordingly? (2) When the sync object wait returns, it still takes ~1.5 ms (from GPUView) before I see a call stack with the engine's symbols. Why this extra time? (not shown in pic) (3) More importantly, my engine should not be throttled by the render thread's inability to present and should kick off sim work for the next frame (at least) a few ms before the render thread gets back control flow. What is the recommended way (API to use) to understand when to start work for the next frame?
