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

[Adam Jackson]

On Tue, 2016-08-16 at 15:55 +0100, Chris Wilson wrote:
> On Mon, Aug 17, 2015 at 03:17:30PM -0700, Eric Anholt wrote:
> > 
> > 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

Just to be screechingly precise: WaitX is not "wait for a reply so you
know your requests have been heard", it's "guarantee that X rendering
has flushed through enough that GL can see it". The only core X request
that comes close to the same semantics is GetImage [1].

If you only have MMIO hardware, like an Indy or a Voodoo, then XSync
would be as strong as WaitX. If you have a single command queue, then
XSync is as strong as WaitX if the server flushes its rendering at
FlushCallback. But even single-queue hardware might implement WaitX as
"acquire breadcrumb for X's rendering queue, insert pipeline bubble for
that breadcrumb into requesting client's GL queue in kernel", which is
what the "does not require a round-trip" language in the WaitX man page
is about.

[1] - Even then, it would arguably be legal for the server to cheat.
ClearWindow followed by a 1x1 GetImage could just return the bg pixel
and leave the fill enqueued to the hardware. Whether that's a server
you want to run is merely a quality-of-implementation issue.

- ajax