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. > >> 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.
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
