[Mesa-dev] [PATCH] dri2: Insert a synchronisation point for glXWaitX

[Chris Wilson]

On Wed, Aug 17, 2016 at 01:34:48PM -0400, Adam Jackson wrote:
> On Wed, 2016-08-17 at 17:50 +0100, Chris Wilson wrote:
> > On Wed, Aug 17, 2016 at 12:13:23PM -0400, Adam Jackson wrote:
> > > 
> > > On Wed, 2016-08-17 at 08:17 -0700, Eric Anholt wrote:
> > >  
> > > > 
> > > > All I'm saying is that it's the thing that was intentionally used for
> > > > this purpose in DRI1 and early DRI2, and maybe if it works we shouldn't
> > > > just accidentally drop it in a refactor.
> > > 
> > > I don't see how the patch in this thread does that. I confess I've been
> > > looped in on this somewhat late, so if there's another thread I should be
> > > looking at for context...
> > 
> > By calling invalidate on the drawable, before the backend will use the
> > surface (either as a texture or as a renderable) it will do a
> > DRI2GetBuffers() round trip. (It is also likely that the buffer will
> > have been invalidated in the meantime and alreadly pending the round
> > trip.) That provides the server with a definite point at which it can
> > insert a synchronisation barrier.
> 
> I understand that. I don't understand how that counts as "dropping" any
> round trips with the server. If anything it's adding one. The patch
> does not remove the copy from real to fake front, which request is
> already a round trip.

I never claimed it did. I only said that we have often have an
invalidation pending on the surface already, and that DRI2 is required
to go through GetBuffers prior to rendering with an invalidated surface.
 
> In fact I'd think the ddx ought to treat that copy as a cue to flush X
> rendering in any case, since that would also cover the equivalent path
> for indirect contexts.

I was under the impression that we didn't have a FakeFront buffer unless
we requested rendering into the front buffer, and so the copy would be
skipped.

However, X will always send a fake front if the real front is requested,
and the real front buffer is requested if either the read or write
buffer is GL_FRONT. So the fake front copy should suffice to trigger the
flush.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre