[Mesa-dev] [PATCH 3/3] dri3: Add a synchronisation point for texture-from-pixmap

Chris Wilson chris at chris-wilson.co.uk
Wed Nov 2 07:43:14 UTC 2016


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


More information about the mesa-dev mailing list