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

[Eric Anholt]

Adam Jackson <ajax at redhat.com> writes:

> 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.

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 wholeheartedly endorse fixing glXWaitX to DTRT and using it.  Having
written about how it's the right way a bunch, are you planning on
writing a piglit test and the patch?  Or should it go somewhere on my
list (it's not near the top)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160817/af419d49/attachment.sig>