On Wed, Nov 02, 2016 at 04:16:55PM +0900, Michel Dänzer wrote: > On 02/11/16 04:13 PM, Chris Wilson wrote: > > On Wed, Nov 02, 2016 at 10:09:26AM +0900, Michel Dänzer wrote: > >> On 22/10/16 07:00 PM, Chris Wilson wrote: > >>> This applies a synchronisation point to GetBuffers() such that binding a > >>> texture-from-pixmap its rendering is serialised with X. This matches the > >>> synchronisation point inside DRI2, but it is also arguable that implied > >>> sync should be explicitly handled by the client by calling glXWaitX() > >>> following the binding of all textures. However, currently glXWaitX() > >>> only operates on the bound drawable and does not actually flush all > >>> Pixmaps associated with the bound context. > >>> > >>> This fixes an issue (output lag) where the compositor calls glXWaitX() > >>> prior to acquiring the damage region from X and binding the > >>> texture-from-pixmap. > >> > >> The X server / driver is responsible for flushing the GPU rendering > >> corresponding to damage events before they are sent to clients. The > >> modesetting driver is known broken in this regard; are there any other > >> setups where this is not happening? > > > > The issue here is that the serialisation is happening outside of damage > > event. Rough timeline: > > > > client X > > > > setup report-on-non-zero damage > > flush + send damage event > > throttle > > start preparing frame more rendering > > query damage region > > reply with region (no damage event, no flush) > > Sounds like the X server / driver needs to flush before sending this > reply to clients as well.
With the above, we already have explicit serialisation points in DRI2 - we can completely forgo the implicit flush-on-damage. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
