On Wed, Oct 06, 2010 at 07:20:11AM -0700, Roland Plüss wrote: > On 10/05/2010 06:48 PM, Aaron Plattner wrote: > > On Tue, Oct 05, 2010 at 08:05:47AM -0700, Roland Plüss wrote: > >> I'm running here into a heavy performance problem on both ATI and nVidia > >> cards and the culprit is the glXSwapBuffers call. I've got here two > >> performance readings showing the problem. > >> > >> The first reading is in a case where performance is somewhat okay. > >> > >> II [OpenGL] OpenGL Timer: BeginFrame: Run Optimizers = 3ys > >> II [OpenGL] OpenGL Timer: BeginFrame: Make Current = 57ys > >> II [OpenGL] OpenGL Timer: BeginFrame: Activate primary GC = 7ys > >> II [OpenGL] OpenGL Timer: EndFrame: Entering = 2312ys > >> II [OpenGL] OpenGL Timer: EndFrame: Activate primary GC = 28ys > >> II [OpenGL] OpenGL Timer: EndFrame: Flush = 27ys > >> II [OpenGL] OpenGL Timer: EndFrame: Swap Buffers = 4238ys > >> II [OpenGL] OpenGL Timer-Total End Frame = 6694ys > >> > >> "EndFrame: Entering" is the time for all rendering for the window > >> (hence the time between leaving BeginFrame and entering EndFrame > >> calls). The flush there is only to make sure it is a problem with > >> glXSwapBuffers. 4ms for a swap I would consider a bit high if the > >> rendering itself is done in <3ms but maybe this is normal, I don't > >> know. But when I show/hide the window to switch to another window > >> rendering the same 3D scene (for testing purpose) and switching back > >> (always only one of the two windows visible, aka mapped to the screen) > >> performance breaks down horribly. > > > > Rendering on the GPU is queued by the rendering commands, and is processed > > asynchronously. This means that you can't assume that just because all of > > your rendering commands have returned, that the rendering is actually > > complete. Also, glXSwapBuffers will queue a swap to occur when the > > rendering is complete, but most GL implementations have code to prevent the > > CPU from getting too far ahead. In particular, at least on our driver, if > > there's a previous swap still pending, glXSwapBuffers won't return until > > that swap is complete. This means that if your rendering is slow on the > > GPU for some reason (e.g. because you have a pixel shader that takes ages > > to complete), you'll see that time show up in the SwapBuffers call for the > > next frame. > > > Ah yeah, though glFlush does an implicit glFinish but looks like it > doesn't.
No, it's the other way around: Finish does an implicit Flush (section 5.2 in OpenGL 4). > Adding a glFinish instead turns the swap into 120ys or so, which sounds > fine. Looks like the problem seems to be elsewhere. Placing glFinish at > various places for testing it looks like glClear (0.18ms raised up to > 6ms) and some FBO activation (0.14ms raised up to 6ms) go through the > roof. No idea why hiding/showing a window causes them to suddenly spike > from fast to horribly slow (especially since you need clearing for shadow > map sooner or later). > > > SwapBuffers from a separate thread should work fine, but you may have > > trouble making sure everything is synchronized correctly. Also, it's > > almost certainly barking up the wrong tree. > > Makes sense. Would be nice if there is a call like in DirectX where you > can check if rendering is done already so you could skip the actual > rendering for a frame while still having the game logic updates done in > that frame. I think you can do that with GL_ARB_sync: http://www.opengl.org/registry/specs/ARB/sync.txt (or the core sync objects in OpenGL 4, which are described in section 5.3, coindicentally right after the section for Flush and Finish). _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: [email protected]
