[Piglit] [PATCH 4/5] Test interaction between fast color clears and glXSwapBuffers.

[Eric Anholt]

Paul Berry <stereotype441 at gmail.com> writes:
> +/**
> + * \file glx-fast-color-clear.c
> + *
> + * On implementations that support fast color clear (e.g. i965/gen7+),
> + * verify that memory writes that were deferred as the result of a
> + * fast clear are properly resolved at the time of glXSwapBuffers.
> + *
> + * We can't use glReadPixels() to do this, since glReadPixels() also
> + * does a resolve, so instead we read the contents of the front buffer
> + * directly from X after the swap.
> + *
> + * Since glXSwapBuffers doesn't actually perform the swap (it simply
> + * queues it to happen later), the test needs to wait for the swap to
> + * occur before reading the front buffer.  If the implementation
> + * supports it, we do so using the GLX_INTEL_swap_event extension.
> + * Otherwise we sleep for 1 second to give time for the swap to occur.
> + */

It seems to me like the test shouldn't have to do this. Particularly
this text:

"glXSwapBuffers is in the OpenGL stream if and only if the display and
drawable are those belonging to the calling thread’s current context;
otherwise it is in the X stream."

and

"Subsequent OpenGL commands can be issued immediately, but will not be
executed until the buffer swapping has completed, typically during
vertical retrace of the display monitor."

Our display and drawable are the calling thread's current context, so
the subsequent ReadPixels should be serialized against the result of the
swap.  I think this is a bug in the X Server, and maybe this is what's
affecting those other frontbuffer-reading tests.

Patch 1-3 and 5 are:

Reviewed-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20130522/b6112dcc/attachment.pgp>