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. > bind texture_from_pixmap > > Here the damage region is not flushed and so the compositor cancels the > dirty region for unflushed pixels. > -Chris > -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
