[Intel-gfx] [Blacklisted][PATCH] Submit batch buffers from flush callback chain

[Kristian Høgsberg]

On Fri, Jul 30, 2010 at 2:29 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Thu, 29 Jul 2010 18:34:19 -0400, Kristian Høgsberg <krh at 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 <krh at 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