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

[Ian Romanick]

On 05/23/2013 09:39 AM, Eric Anholt wrote:
> Paul Berry <stereotype441 at gmail.com> writes:
>
>> On 22 May 2013 16:20, Eric Anholt <eric at anholt.net> wrote:
>>
>>> 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.
>>>
>>
>> But this test doesn't use ReadPixels (see the documentation above); it uses
>> xcb_image_get().  Does that change your opinion about whether this is an X
>> server bug?
>
> I read the "can't just ReadPixels" as "can't just ReadPixels the back
> buffer".
>
> You should be able to serialize with XGetImage() by just doing
> glXWaitGL(), but I think that's going to be broken in the way I was
> seeing here.  Even if it's broken, you can wait for your swap to be done
> much easier using GLX_OML_sync_control.
>
> But even easier I think, you just want to glReadPixels on the front
> buffer instead of the back, avoiding the need for using X to get the
> front buffer pixels entirely.

I agree with Eric for this test.  However, I think we need another test 
that will use X to read the pixels.  We need a test that calls 
glXSwapBuffers on a drawable that is *not* current to the thread. 
Kristian noticed that at least TF2 does this.  We probably ought to have 
a similar test for multisample resolves.

> _______________________________________________
> Piglit mailing list
> Piglit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/piglit