OpenGL dropping frames with 0.7.0.0

I'm definitely seeing improvement with 355.84. With Oculus Room Tiny (GL) there's still about 20 dropped frames in the beginning over the course of the first 30 seconds or so but after that it seems much more stable, only dropping a frame every minute or two.

So it looks like it's a problem in the driver... Well it's still "beta" so it will be probably fixed in the future.

It also mean that our GL powered applications don't do anything wrong by themselves (and that's good news). I understand that they probably prioritize their developpement effort to the DirectX API, since it's the one that is the most relevent for gaming...

It's annoying but we have to wait and see if they stabilize the perfomance problem over time ^^"

I am also getting similar issues of a GTX 770 with latest driver 355.84 and two monitors, 1 60 hz and 1 120hz lightboosted. I get a feeling since I am using Ogre 1.10 with the OpenGL 2.0 render system that legacy 2.0 stuff / ways of using OpenGL is causing the NVIDIA driver to stall unpredictably. I reduced my scene to basically nothing and it still happens, worse than the screenshots already posted. If I close Chrome, Thunderbird, and Steam, then it gets better and approaches the screenshots posted.

What is most surprising is that the OculusRoomTiny GL demo does not have frame drops and I can't figure out why. Does glFramebufferRenderbuffer play badly with the DirectX interop or Oculus SDK? Is the redundanct glBindFramebuffer causing pipeline flushes or stalls? No clue. Is it because the RoomTiny's use of glFramebufferTexture2D for color and depth attachments more favorable instead of glFramebufferRenderbuffer?

Using glintercept, I was able to obtain a OpenGL command trace, and I'm not sure what is causing it. Just some food for thought.

glGetString(GL_VERSION)="4.5.0 NVIDIA 355.84" 
glBindFramebufferEXT(GL_FRAMEBUFFER,2)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_DEPTH_ATTACHMENT,GL_RENDERBUFFER,0)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_STENCIL_ATTACHMENT,GL_RENDERBUFFER,0)
glBindFramebufferEXT(GL_FRAMEBUFFER,2)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_DEPTH_ATTACHMENT,GL_RENDERBUFFER,1)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_STENCIL_ATTACHMENT,GL_RENDERBUFFER,1)
glBindFramebufferEXT(GL_FRAMEBUFFER,2)
glEnable(GL_FRAMEBUFFER_SRGB)
glScissor(0,0,1182,1464)
glEnable(GL_SCISSOR_TEST)
glMatrixMode(GL_PROJECTION)
glLoadMatrixf([0.929789,-0.000000,0.000000,0.000000,0.000000,-0.750974,0.000000,0.000000,0.015672,-0.000000,-1.000001,-1.000000,0.000000,-0.000000,-0.010000,0.000000])
glMatrixMode(GL_MODELVIEW)
glMatrixMode(GL_MODELVIEW)
glLoadMatrixf([0.996551,-0.038283,0.073623,0.000000,0.020330,0.972821,0.230664,0.000000,-0.080452,-0.228372,0.970244,0.000000,0.025994,-0.096070,-0.782788,1.000000])
glDisable(GL_SCISSOR_TEST)
glBindFramebufferEXT(GL_FRAMEBUFFER,2)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_DEPTH_ATTACHMENT,GL_RENDERBUFFER,0)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_STENCIL_ATTACHMENT,GL_RENDERBUFFER,0)
glBindFramebufferEXT(GL_FRAMEBUFFER,4)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_DEPTH_ATTACHMENT,GL_RENDERBUFFER,0)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_STENCIL_ATTACHMENT,GL_RENDERBUFFER,0)
glBindFramebufferEXT(GL_FRAMEBUFFER,4)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_DEPTH_ATTACHMENT,GL_RENDERBUFFER,2)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_STENCIL_ATTACHMENT,GL_RENDERBUFFER,2)
glBindFramebufferEXT(GL_FRAMEBUFFER,4)
glEnable(GL_FRAMEBUFFER_SRGB)
glScissor(0,0,1182,1464)
glEnable(GL_SCISSOR_TEST)
glMatrixMode(GL_PROJECTION)
glLoadMatrixf([0.929789,-0.000000,0.000000,0.000000,0.000000,-0.750974,0.000000,0.000000,-0.015672,-0.000000,-1.000001,-1.000000,0.000000,-0.000000,-0.010000,0.000000])
glMatrixMode(GL_MODELVIEW)
glMatrixMode(GL_MODELVIEW)
glLoadMatrixf([0.996551,-0.038283,0.073623,0.000000,0.020330,0.972821,0.230664,0.000000,-0.080452,-0.228372,0.970244,0.000000,-0.038006,-0.096070,-0.782788,1.000000])
glDisable(GL_SCISSOR_TEST)
glBindFramebufferEXT(GL_FRAMEBUFFER,4)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_DEPTH_ATTACHMENT,GL_RENDERBUFFER,0)
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER,GL_STENCIL_ATTACHMENT,GL_RENDERBUFFER,0)
glFlush()
wglDXUnlockObjectsNV(0000007DE27949FE,1,0000007D33F88D40)=true 
glFlush()
wglDXUnlockObjectsNV(0000007DE27949FE,1,0000007D33F88480)=true 
wglDXLockObjectsNV(0000007DE27949FE,1,0000007D33F88D00)=true 
wglDXLockObjectsNV(0000007DE27949FE,1,0000007D33F88900)=true 

I'm not quite sure what the problem is, but would it be possible to try to match the Oculus GL sample as close as possible since that seem to be working for you?

Unfortunately, that is not quite possible, as Ogre is suppose to be an engine, and all that detail is abstracted from me. Like I use it's C++ API and it magically transforms it into OpenGL. Changing it to be like the OpenGL of the RoomTiny demo would basically be rewriting the graphics engine or starting over with not engine.

I guess my main question would be if there is anything suspect or wrong with the OpenGL trace I provided which causes the frame drops? Or is this something that only an NVIDIA engineer can answer.

kokonut, if you have a way to do it, could you check and see if your "present" or "swap" call is doing it with vsync enabled or disabled? To avoid the frame drops, you need to make sure that vsync is not enabled.

Also you need to make sure that the swap texture set indices are increment just before you render into them instead of when you submit them. See how ORT is doing it as an example.

Yes, I vsync was already disabled. I verified with a debugger that wglSwapIntervalEXT() is called with 0 and every other vsync option is set to off. Also confirmed with OpenGL command tracing.

Swap textures are also being incremented properly like in the example before GL commands are being executed.

I'm profiling with NVIDIA nSight, and getting strange stalls of mostly 1/75 * 2 length (37.5) and huge stalls of 9 ms between eye draws, but before SubmitFrame (white space in nSight). Also, each texture in the SwapTextureSet has it's own Framebuffer due to how it's designed in OGRE, so I don't know if that causes performance/locking issues.

It looks like a CPU side block (glFunctions are pretty small), so I will have investigate more on my end.

After switching over to a newer version of Ogre and a OpenGL 3+ programmable only pipeline (no more fixed function pipeline), I was able to solve most of my stuttering issues and receive app rendering graphs similar to others have reported (very occasional frame miss).

I think the lesson learned is that fixed function pipeline rendering causes severe latency issues when it comes to Nvidia drivers and VR :oops: . Not that anyone should use it nowadays. Strangely enough this wasn't an issue in 0.4.0. Maybe because the textures provided by the Oculus SDK is actually DirectX interop textures, and the older method was a blit of native OpenGL texture to DirectX internally and this newer method is directly rendering to a DirectX texture?

Hopefuly the next driver and/or SDK update fixes the remaining latency issues.

There is a new driver, and the download link was moved here: https://developer.nvidia.com/gameworks- ... er-support

Doesn't solve the problem.