Skip to main content
craigmcn
Up and Coming
June 29, 2015

OpenGL dropping frames with 0.6.0.1

Hi,

I'm getting lots of dropped frames in our application, and I'm at a loss to explain them. They happen even in empty blank scenes that render at about 770fps (1.3ms per frame, varying only by a percent or two) to a single 1920x1080 full screen app. I render the same empty scene to the Oculus and I'm getting 2 or 3 dropped frames per second, and some very odd values reported in the performance hud. The frame rate graph is pretty noisy, with some obviously wrong spikes to 100's of fps and the dropped frames clearly visibly.



Profiling shows all the work being done in ovrSubmitFrame() (80% of CPU time), and our app basically idle. When we add our full scene I'm getting frame times of 2ms to 4ms in a full screen mode, but still getting exactly the same performance in the Oculus (and a very similar profile), hovering around 75fps, with occasional glitches that result in dropped frames (and a very unpleasant judder for the user).

The render pipeline has a few stages (multiple shadow renders, reflection renders, HDR tone map pass) but the 980GTX chews threw all this without breaking sweat in full screen.

I can't see anything in my render loop that would cause the problem, it's based very closely on the OculusRoomTiny GL sample, but the performance hud show something weird is going on.

Any ideas on what's causing this are welcome.

(edit : I was getting very similar behaviour in 0.6.0.0)

Cheers,

Craig.

    20 replies

    Show previous replies
    volgaksoy
    Meta Employee
    July 3, 2015
    Looks like you're on Windows 7. Even though you shouldn't have to, would you mind disabling Aero (desktop composition) to see if that helps or hurts?
    craigmcnAuthor
    Up and Coming
    July 3, 2015
    "volgaksoy" wrote:
    Looks like you're on Windows 7. Even though you shouldn't have to, would you mind disabling Aero (desktop composition) to see if that helps or hurts?


    Yep, I'm on Win7. I've set the theme to Windows 7 Basic (which should turn off all the Areo stuff?) No difference in the behaviour, the OculusRoomTiny GL demo drops a frame or two every second (very much at random), while the DX11 version is locked solid at 75, never seen it miss a frame. My app behaves in the same way, no noticable difference between the two.

    Thanks for the suggestion though!
    Constellation
    Up and Coming
    July 12, 2015
    My results are similar although I'm only dropping a frame about every ten seconds. Both the DirectX and GL OculusRoomTiny will drop a few frames when starting up but after that DirectX never drops again. Disabling Aero didn't seem to have any effect.

    drop.png
    craigmcnAuthor
    Up and Coming
    July 12, 2015
    "JeffBail" wrote:
    My results are similar although I'm only dropping a frame about every ten seconds. Both the DirectX and GL OculusRoomTiny will drop a few frames when starting up but after that DirectX never drops again. Disabling Aero didn't seem to have any effect.


    It's partially related to scene complexity, I only drop a frame every two or three seconds the RoomTiny Open GL. I was dropping about 3 or 4 a second on our app, but by gutting the complexity of it I've managed to get it down to every second or two. Not perfect, and the visual quality has suffered, but the user experience is a bit improved. (and it'll hit 400fps in a single 1920x1080 window, so there should be a ton of headroom there)
    gaelhonorez
    Participant
    August 3, 2015
    Hi,

    We a are experiencing the exact same problem (DX stable, GL dropping) on some our test machines, both on our app and the oculus GL example scene.

    ie. my dev machine with a 980 has the problem. The same one (same dell station) with a 970 has not.

    Same driver version, same runtime (0.6.0.1) on both machines.

    Any news on this issue ?
    MichaelNikelsky
    Up and Coming
    August 3, 2015
    The problem seems to be the directX-OpenGL interOP that is used. This seems to effectively block any double buffering and just allows the application to continue rendering the next frame if the current one has been rendered (which essentially means it calls a glFinish). In our application this reduced renderperformance by at least 20-40%, so instead of needing to render 75fps in Stereo we need to render something like 100fps in stereo to prevent the oculus lib from dropping frames.

    Oculus should really create a specialized OpenGL path in their drivers instead of relying on these interop extensions.
    gaelhonorez
    Participant
    August 3, 2015
    I doubt that it's only linked to a performance drop, as the tinyRoom example drops frames on a 980 GTX. Even rendering a black screen drops frames.

    The main difference between both stations is that mine is running a 980 with vsync off on a 60hz monitor (no problem in DX, drop frames in GL), while the other is running a 970 with vsync on on a 120hz monitor (no problem in GL or DX).

    The openVR GL scene example seems to not suffer from such problem, but I don't feel like converting the whole code right now to a new api.
    jherico
    Inspiring
    August 3, 2015
    "MichaelNikelsky" wrote:
    Oculus should really create a specialized OpenGL path in their drivers instead of relying on these interop extensions.


    That's basically what they had in 0.5, and it sucked. With DirectX, much more of the guts of the system resides in the WIndows internals, so it's easier to interact with it in the ways that Oculus needs (getting pixels from the GPU memory to the display on the Rift even though it's not recognized as a conventional monitor).

    With OpenGL, because Microsoft doesn't really support GL past version 1.1, every vendor has to supply the full GL stack in their own driver, so all Oculus can do it inject their functionality into some common well known API. The upshot is that using this mechanism imposed some serious limitations on the OpenGL functionality. For direct mode, the OpenGL rendering window HAD to be the exact same size as the Rift resolution and it had to be visible on the screen at all times, or the Rift would stop updating. It also had the effect of breaking v-sync for the non-Rift GL window, with no way to fix it, so it made it troublesome to support switching between HMD and non-HMD mode in applications.

    The real solution is not to patch the drivers, but to get direct support for VR displays in the GPU drivers and operating systems. But that kind of support is slow in coming, because much as we'd like otherwise, VR is not the top priority of Apple/Microsoft or nVidia/AMD. Even if it were, building the kind of support that is needed involves a pretty long design and engineering pipeline. This is pretty clear given how long it's been between the announcements and feature set lists of the nVidia and AMD 'VR extensions' and the fact that they're still not here.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    gaelhonorez
    Participant
    August 4, 2015
    Never-mind, the other station had a 780 ti, witch in our case is faster than a 980.

    But even there, we have some drops even the scene is empty.
    gaelhonorez
    Participant
    August 28, 2015
    Hi,

    Tested oculusRoomTinyGL in 0.7.0.0 with the recommanded nvidia drivers, the bug is still there.

    Any chance to have a quickfix as it's REALLY inconvenient for developing anything using OGL for the rift ?
    Terms & ConditionsAccessibility statement