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

[Chris Wilson]

On Mon, Aug 17, 2015 at 03:17:30PM -0700, Eric Anholt wrote:
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > "X rendering calls made prior to glXWaitX are guaranteed to be
> > executed before GL rendering calls made after glXWaitX."
> >
> > The goal is to implement that without adding a round-trip to the
> > Xserver. Adding one using XSync() is easy, but we can piggy-back
> > another, the DRI2GetBuffers request made to update the render buffers
> > before the next rendering (thus satisfying the condition of flushing all
> > X operations before the next GL rendering). To this end we can just flag
> > the DRI2 buffers as invalid, and the driver will refresh them in due
> > course. If the DRI2 buffers are, or will be, invalid due to damage from
> > X or through a SwapBuffers call, we will not have to add another
> > roundtrip as the single DRI2GetBuffers will refresh over multiple
> > invalidates.
> >
> > This should fix the historic issue that glXWaitX() has been unreliable,
> > but has recently found itself a new trigger will the removal of
> > unnecessary glViewport calls:
> 
> I think XSync makes more sense.  It's cheaper, and it does exactly what
> you're supposed to do at this point -- make sure that all your X
> requests have been processed, so that any GL batchbuffer flushes happen
> after that.

Quoting Adam Jackson:

This is a bit incorrect. For direct contexts, DRI2's WaitX becomes
DRI2CopyRegion from real-front to fake-front. That _does_ generate a
reply, but whether it flushes the X rendering queue appears to be up to
the driver's CopyRegion{,2} hook; at least ms doesn't do anything
special for that case, although presumably glamor's Flush in
BlockHandler will fire. (DRI3 does something similar, although
apparently uses core X CopyArea to do it instead of present? Sigh.)

Both the DRI2 and DRI3 paths are broken, in fact, since they will only
emit the copy if there's a current context (per spec) and drawable
(maybe implied by spec but questionable), and only for that drawable
(definitely wrong). They ought to emit a real GLXWaitX request
unconditionally, which the server then ought to have enough context to
handle correctly since it keeps track of current drawables globally
(and knows about all the different DRIs). Getting this right isn't
hard, but as with pretty much everything else about multiple GL
clients, people have historically decided it was too difficult to want
to care about, thus ensuring it gets even more difficult to fix over
time...

The WaitX man page and GLX spec are wrong to mention XSync at all,
which is just GetInputFocus on the wire and AFAIK no DDX ever has
interpreted that as a hint to flush rendering; a future GLX spec update

-- 
Chris Wilson, Intel Open Source Technology Centre