[PATCH xserver] Pass ClientPtr to FlushCallback
michel at daenzer.net
Wed Aug 3 00:56:04 UTC 2016
On 03.08.2016 09:40, Eric Anholt wrote:
> Keith Packard <keithp at keithp.com> writes:
>> Michel Dänzer <michel at daenzer.net> writes:
>>> From: Michel Dänzer <michel.daenzer at amd.com>
>>> This change has two effects:
>>> 1. Only calls FlushCallbacks when we're actually flushing data to a
>>> client. The unnecessary FlushCallback calls could cause significant
>>> performance degradation with compositing, which is significantly
>>> reduced even without any driver changes.
>> Seems like a completely reasonable plan. As you can see, the original
>> goal was to have the callback called only once when flushing output to
>> multiple clients though. That appears to only be used by the record
>> extension, so perhaps we just don't care.
I suspect that the record extension could also take advantage of this
change, but I'm not sure and can't say that I care too much. :)
>>> 2. By passing the ClientPtr to FlushCallbacks, drivers can completely
>>> eliminate unnecessary flushing of GPU commands by keeping track of
>>> whether we're flushing any XDamageNotify events to the client for
>>> which the corresponding rendering commands haven't been flushed to
>>> the GPU yet.
>> Is this something we should be doing in either glamor or DIX itself? It
>> looks like the ATI driver has a number that is incremented every time
>> commands are sent to the GPU and that clients need to be flushed
>> whenever they haven't been flushed since the last time that number was
>> I don't even know how this works in the generic modesetting driver at
>> this point; what makes sure that glFlush is called before data are sent
>> to the client?
> We glFlush in the BlockHandler in glamor.
That's not sufficient for correctness with direct rendering compositors,
because FlushClient can be called before BlockHandler.
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: OpenPGP digital signature
More information about the xorg-devel