glXSwapBuffers very slow, potential problems?

[Roland Plüss]

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. 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.

-- 
Mit freundlichen Grüssen
Plüss Roland

Leader und Head Programmer
- Game: Epsylon ( http://www.indiedb.com/games/epsylon ,
http://epsylon.rptd.ch )
- Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
, http://dragengine.rptd.ch )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php
) and others

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20101006/b073a5bd/attachment.pgp>