cancel
Showing results for 
Search instead for 
Did you mean: 

ovr_Submit and AppDroppedFrameCount unreliable in OpenGL application

jherico
Adventurer
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?  
6 REPLIES 6

galopin
Heroic Explorer
If ovr_Submit take 15ms, it is because it has poll after failing to catch the vsync, so the extra duration and frame drop.

I bet your best way to analyse what happen is to use GPUView, you should be able to see what happen that made you fail a frame.

volgaksoy
Expert Protege
Hi jherico,

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.

jherico
Adventurer
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.  

galopin
Heroic Explorer
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

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

stevee344
Honored Guest
MyPrepaidCenter is famous among users due to its applicability with any Visa or Master – Prepaid Debit Card, Credit Card and Gift Cards.