Forum Discussion
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.
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
- I've done a bit more testing, and it would seem that ovrHmd_SubmitFrame is not performing as expected.
I've hacked my rendering loop so it looks like this:
while (1)
{
render shadows
render eye 0
render eye 1
glFinish()
record elapsed time since timer reset
ovrHmd_SubmitFrame
reset timer
render to mirror window
}
This should give me the true time spent in my code doing all the draw and waiting till it's finished. The rest of the frame time is spent in the in the SubmitFrame() call. Running this on an empty scene I see consistent times of between 3 and 3.2ms for my code/drawing. However I'm still dropping frames (as that previous HUD screen grab shows)
Here's the other page of information, the numbers here seem very similar to the SDK sample apps.
The render timings page also shows similar numbers for the Compositor time and the tracking to TW time, it's just the very noisy frame rate and missed frames that I can't explain.
All fingers point to SubmitFrame() doing something odd here, any ideas are welcome.
Cheers. - I'm not sure about this one, let me see what I can find out.
"cybereality" wrote:
I'm not sure about this one, let me see what I can find out.
Thanks, everything else is running beautifully on the DK2, it's just these dropped frames that are ruining the experience.- One of the engineers suggested that there's a chance your whole computer is freezing up at the kernel level due to a bad driver provided by another hardware manufacturer. Can you run this tool to check for problems? http://www.thesycon.de/deu/latency_check.shtml
- Are you familiar with GPUView? It's a public tool from Microsoft which will break down exactly what the GPU is doing at one specific time. What we commonly see in how is that an updating window like Firefox or Outlook will temporarily stall the GPU just enough that we miss a frame. A tool like GPUView will point exactly to the culprit.
A video explaining the tool: https://www.youtube.com/watch?v=WeZazyXsp7o
GPUView is part of the Windows Kit available here: https://msdn.microsoft.com/en-us/windows/desktop/bg162891.aspx - You said your sample is based on the OculusRoomTiny (GL) sample. Are you seeing similar dropped frame problems there?
If not, I'd recommend checking to make sure you're not accidentally doing a vsync'ed swap after rendering the mirror window. That will definitely cause the app to judder on the HMD-side because your main display is probably running at a different frame rate (60Hz?) than the HMD which is trying to hit 75Hz. - Good idea. Unfortunately latency doesn't seem to be the issue. The latency checker shows a maximum of 166us over about 10 seconds, generally hovering about 70-100us.
It's fairly new bit of hardware, GTX980, i7 2700K @ 3.5GHz, nothing unusual about it. We do lots of other graphic app development and haven't seen any issues with this machine before. We're setting up a second Oculus machine at the moment, so I'll test on that as soon as I can get to it.
I've got wglSwapInterval() set to zero so the SwapBuffers on my mirror window shouldn't be blocking. (Removing the SubmitFrame() call gives me the expected 300-ish fps that my 3ms timings suggest I should be getting)
Grabbing the GPUView tool even as we speak. I'll let you know what I find. I have tried killing everything else on the machine, making sure it's the only thing running and still no joy.
Just tested the SDK sample apps and noticed something very interesting. Adding the render time HUD into the RoomTiny samples, the OpenGL version is showing dropped frames and glitches in the frame rate (not as bad as my code, but the render is much simpler), while the DirectX11 version is absolutely locked at 75 and doesn't skip a single frame (over a few minutes at least, OpenGL had dropped about 25 frames in that time)
Thanks! - You might want to check out the "Poor performance with new SDK" thread here https://forums.oculus.com/viewtopic.php?f=20&t=24361. There's speculation that the issue with long submit times has something to do with locking and unlocking the textures between DirectX (which is allocating them) and OpenGL (which has to call wglDXUnlockObjectsNV to write to them).
"JeffBail" wrote:
You might want to check out the "Poor performance with new SDK" thread here https://forums.oculus.com/viewtopic.php?f=20&t=24361. There's speculation that the issue with long submit times has something to do with locking and unlocking the textures between DirectX (which is allocating them) and OpenGL (which has to call wglDXUnlockObjectsNV to write to them).
Thanks, I have been keeping an eye on that thread as well, seems I'm not the only one seeing fragile performance from OpenGL."DeanOfTheDrivers" wrote:
Are you familiar with GPUView? It's a public tool from Microsoft which will break down exactly what the GPU is doing at one specific time. What we commonly see in how is that an updating window like Firefox or Outlook will temporarily stall the GPU just enough that we miss a frame. A tool like GPUView will point exactly to the culprit.
A video explaining the tool: https://www.youtube.com/watch?v=WeZazyXsp7o
GPUView is part of the Windows Kit available here: https://msdn.microsoft.com/en-us/windows/desktop/bg162891.aspx
GPUView show interesting thing, if slightly cryptic :) I can definitely see a stall happening, it would appear it's not actually missing an entire frame, just presenting them at the wrong times
Here's a grab over a number of frames : (click for the full image, the board crops them all)
In the middle you can see a large gap between two frames (resulting in 20ms between frames), the next frame gets presented early (only 10ms after the last one), and by the time the third frame starts it's all back into sync again.
zooming in (and expanding out all the processes)
You can see the region I've highlighted, The oculus server and my app are completely idle, and nothing else seems to being anything out of the ordinary.
If you can interpret anything else from these traces I'd love to know.
Cheers.
