cancel
Showing results for 
Search instead for 
Did you mean: 

Bubbles in the GPU queue at the start because of ovr_submitFrame

rajabala
Honored Guest
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

9703ix9h3bfb.png
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? 
0 REPLIES 0