On Mon, 8 Mar 2010 20:13:21 +0100 Mario Kleiner <[email protected]> wrote: > The glxgears.c of mesa only does draw -> glXSwapBuffers -> draw -> > glXSwapBuffers -> ... > It doesn't use any of the new api's, so the only way it can block is > probably via the DRI2ThrottleClient call when requesting a "new" > backbuffer. > > I see at least one problematic thing. In the xserver's dri2.c file in > DRI2SwapBuffers(), the pPriv->swapsPending++ statement is *after* the > call into the ddx's I830DRI2ScheduleSwap() function, instead of > *before* it. If a swap completes inside the ddx, it will call > DRI2SwapComplete() which will do a pPriv->swapsPending-- before it > was incremented to mark a swap as pending. That is, if swapsPending > was zero before, it will now wrap around to 0xffffffff. This will > happen if the fallback_blit path inside the ddx is used, e.g., if the > drawable is not visible (yet).
Or if composited; it may be offscreen. > > Not sure if this by itself is sufficient for the hang, because the > call to pPriv->swapsPending++ after return from I830DRI2ScheduleSwap > () should fix this, but if something else goes wrong and an error > path is taken or an event not delivered, then swapsPending could get > stuck at 0xffffffff or a similar high number, which would trigger > DRI2ThrottleClient and block the client connection without ever > waking it up again, as clients are only woken up if a swap completes, > which can't happen if no swap is pending. -> hang in _XReply on the > client side. > > So we should probable move pPriv->swapsPending++ before the call to... > > ret = (*ds->ScheduleSwap)(client, pDraw, pDestBuffer, pSrcBuffer, > swap_target, divisor, remainder, func, > data); > > ... in DRI2SwapBuffers() and probably add a pPriv->swapsPending-- > into the error handling path directly after the call to ds- > >ScheduleSwap. Yep, that's the safer thing to do. Florian, can you give that a try and see if it helps your situation? Thanks, -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
