Skip to main content
phammer
New Participant
August 5, 2015

SDK 0.6.0 stalls ovrHmd_SubmitFrame

Hello,

I've encountered stalls in "ovrHmd_SubmitFrame" with SDK 0.6.0 (DX11).
My performance capture is telling me, that "ovrHmd_SubmitFrame" blocks for 13 ms, but only every second frame. The first frame always returns intantly. I'm suspecting some double-buffering / inter-frame dependency issue here, but there is nothing obvious in my implementation. TinyRoom example is working fine.

Any ideas how to solve that?

Best regards,
Philip

    3 replies

    cybereality
    Inspiring
    August 5, 2015
    Did you force the v-sync settings on your GPU? It should be set to application controlled.

    Also, can you try the latest SDK version.
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    phammerAuthor
    New Participant
    August 6, 2015
    Thanks for the answer and no, vsync is not forced by the driver.
    Again, what I'm seeing is not a constant stall, it's alternating between frames. I've got a very simple scene taking ~7-8 ms to render. If I skip calling ovrHmd_SubmitFrame, I get the expected high framerates of > 100 FPS.

    The frametime is constant, but ovrHmd_SubmitFrame blocks alternating from frame to frame for 5-6 ms (sync to 75 Hz) and 18-19 ms (sync to 35.5 Hz) .
    When I look at a capture from brofiler I see the following:

    frame 1: 13 ms (8 ms frametime + 5 ms block in ovrHmd_SubmitFrame)
    frame 2: 26 ms (8 ms frametime + 19 ms block in ovrHmd_SubmitFrame)
    frame 3: 13 ms (..)
    frame 4: 26 ms (..)
    etc.

    In the meanwhile I've tried SDK 0.6.0.1 Beta, reverted my NVIDIA driver to 350.12, got rid of all lock()s in the frame, but it didn't help.


    edit: I can't remember having this problem with SDK 0.4.4 (from my previous libovr integration).
    volgaksoy
    Meta Employee
    August 6, 2015
    Hi phammer,

    Would you mind checking to see if you're seeing this issue in your own application only vs. our SDK samples (specifically OculusRoomTiny DX11, GL and OculusWorldDemo)?

    Also I'd like to suggest that you do a careful comparative analysis of your code vs. the SDK samples. If it's not happening in the SDK samples, then a wild guess would be that you might be handling the swap texture set index incrementation incorrectly. Failure could cause one of the swap texture sets to be locked up by the compositor, keeping the app from being able to render to it while it's in use by the compositor.

    Hope that helps.

    Edit: Just saw that you had already said RoomTiny works fine, so I suppose my statement about swap texture sets might be even more valid, but still a careful comparison would be important as it's hard for us to know exactly what you might be missing in your implementation.
    Terms & ConditionsAccessibility statement