On Fri, Jul 30, 2010 at 2:29 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > On Thu, 29 Jul 2010 18:34:19 -0400, Kristian Høgsberg <k...@bitplanet.net> > wrote: >> There are a few cases where the server will flush client output buffers >> but our block handler only catches the most common (before going into >> select). >> If the server flushes client buffers before we submit our batch buffer, >> the client may receive a damage event for rendering that hasn't happened yet. >> >> Instead, we can hook into the flush callback chain, which the server will >> invoke just before flushing output. This lets us submit batch buffers >> before sending out events, preserving ordering. >> >> Fixes 28438: [bisected] incorrect character in gnome-terminal under compiz >> https://bugs.freedesktop.org/show_bug.cgi?id=28438 >> >> Signed-off-by: Kristian Høgsberg <k...@bitplanet.net> > > A flush callback makes more sense than a block handler. Is there a guide > to the various hooks the xserver uses for io and the meaning of those > barriers between clients?
Not that I know, I discovered the callback when I was tracing the protocol flushing code. And as it is, it doesn't catch all flush cases - I sent a couple of patches to xorg-devel to cover those. > Do we have an idea of the impact this has in > non-damage situations, does it impact aa10text? ;-) It might, the flush that was causing the premature damage events wasmainly the FlushAllOutput() call in Dispatch(). It kicks in when the smart scheduler decides that a client has had the X server for too long. I guess the question is, do we normally fill up a batch buffer when we use up the entire time slot or will we be flushing too early... > In intel_dri.c we > manually flush the batchbuffer, should this be better expressed in terms > of a call to a general flush func? Yes, now that we submit in the flush callback, the manual flush shouldn't be necessary. The client will wait for the reply before it continues rendering, so we will hit the flush callback before the reply is written to the client. > For what's it is worth, I approve of this change. :) Thank you, that's important to me :) Kristian _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
