On 03.08.2016 09:40, Eric Anholt wrote: > Keith Packard <[email protected]> writes: > >> Michel Dänzer <[email protected]> writes: >> >>> From: Michel Dänzer <[email protected]> >>> >>> 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 >> changed? >> >> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
