I'm working on an application using a custom OpenGL engine. I've recently started tracking the the ovrPerfStatsPerCompositorFrame::AppDroppedFrameCount value, watching it rise constantly. However, in many cases it's rising even though I'm well under budget in terms of time. Looking at application traces I'll often see the dropped frame count rise even though I never see an interval between the end of the last ovr_Submit call and the start of the next of more than 6ms. Further, sometimes even when that interval is that low, the ovr_Submit call will take more than a frame to return. So I'll see "6ms render -> 5 ms ovr_Submit" over and over and then suddenly I'll see "6 ms render -> 15 ms ovr_Submit". This seems to increment the AppDroppedFrameCount even though I was under budget and the only reason I missed the next frame was because ovr_Submit was blocking.
Why is ovr_Submit sometimes for no apparent reason taking longer than a frame to return?
As galopin stated, it'd be easiest to look at the given "offending" frame in GPUView or NSight to see why the offending frame didn't play nice.
The thing you should be aware of is the fact that even though ovr_SubmitFrame interval might have been a max of 6 ms, that isn't the only thing that determines how much you're pushing your system as it's just looking at the CPU side of things. I don't know how GPU intensive your app is, but also note that the compositor will have to jump in and do its work as well that can also steal away GPU cycles. Depending the eye texture resolutions and the number of layers you're using, this can be a fairly significant perf draw for the GPU. To that end, when you see a dropped frame, it'd be good to also look at the other numbers in the frame, specifically the GPU timing numbers for the current and previous frames.
Hmmm... it's tricky. We have 3 active OpenGL contexts. One is responsible for primary rendering, one is responsible for rendering the UI layer for compositing (using third party software: QML) and another is responsible for texture transfers from CPU to GPU. At no point do I ever see GPU usage exceed 30%, but I suppose some kind of internal driver locking could be responsible. I'll do further investigation. Thanks for the feedback.
Here a link in the forum where i show how to start gpuview from within you app for ease and below an example of what you see : https://forums.oculus.com/community/discussion/comment/306731#Comment_306731
you can also use the custom script they have in the libovr/tools folder
OpenGL performs many complex operations—transformations, lighting, clipping, texturing, environmental effects, and so on—on large data sets. The size of your data and the complexity of the calculations performed on it can impact performance MyPrepaidCenter.com