Forum Discussion
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
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
- 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. - 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). - 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.
