[PATCH xserver] Pass ClientPtr to FlushCallback

Michel Dänzer michel at daenzer.net
Wed Aug 3 08:30:53 UTC 2016


On 03.08.2016 09:51, Michel Dänzer wrote:
> On 03.08.2016 09:40, Eric Anholt wrote:
>> 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.
>>>
>>> 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.
>>>
>>> Signed-off-by: Michel Dänzer <michel.daenzer at amd.com>
>>> ---
>>>
>>> See https://lists.freedesktop.org/archives/amd-gfx/2016-August/000977.html
>>> for an example of how to take advantage of this change to eliminate
>>> unnecessary GPU flushes.
>>
>> Note: Mesa's DRI2 is (supposed to be) doing XSync() during glXWaitX() to
>> ensure that the server has processed the client's X requests and flushed
>> its batchbuffers, so that the kernel serializes the batchbuffer from X
>> before the next rendering by Mesa.  I think your xf86-video-ati patches
>> will break that.
> 
> Can you elaborate how? I honestly can't imagine.

I guess you mean because we're no longer flushing when sending out the
replies to whatever requests Mesa uses for glXWaitX? That could indeed
be an issue (at least in theory, see below), but right now, neither
dri2_wait_x (which uses DRI2CopyRegion) nor dri3_wait_x (which uses
CopyArea) actually wait for the request reply AFAICT, so it doesn't make
much difference in practice.

I guess the price question is: Can the replies to these requests be
flushed to the client before the BlockHandler?


Anyway, we still always flush in the BlockHandler, so even with my
patches our drivers are strictly more correct than the modesetting
driver. :)


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160803/9063ed83/attachment.sig>


More information about the xorg-devel mailing list