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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
