Skip to main content
jherico
Inspiring
January 6, 2017

ovr_Submit and AppDroppedFrameCount unreliable in OpenGL application

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

    galopin
    Up and Coming
    January 6, 2017
    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
    Meta Employee
    January 6, 2017
    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.
    jhericoAuthor
    Inspiring
    January 8, 2017
    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.  
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    galopin
    Up and Coming
    January 9, 2017
    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
    New Participant
    June 28, 2019
    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
    New Participant
    March 31, 2020
    MyPrepaidCenter is famous among users due to its applicability with any Visa or Master – Prepaid Debit Card, Credit Card and Gift Cards.
    Terms & ConditionsAccessibility statement