[PATCH] retrace: Implement glxCopySubBufferMESA

[Chad Versace]

On 10/28/2013 02:25 PM, Alexander Monakov wrote:
> On Mon, 28 Oct 2013, Carl Worth wrote:
>>>> I'll note that this function, like glFinish and glFlush, is almost, but not
>>>> quite, a candidate for "this call concludes drawing a frame" flag.
>>
>> You're definitely right. It's strange to replay this chrome trace with
>> apparently hundreds of frames in it only to then see:
>>
>> 	Rendered 6 frames in 10.9526 secs, average of 0.547816 fps
>>
>> I'm not sure what you mean with "almost, but not quite".
>
> ISTR this was discussed previously, but I can't find a reference.  The issue
> I'm referring to, glFlush and glFinish (and now glXCopySubBufferMESA) do not
> have "hand off a completed frame to the windowing system and start rendering
> another one" semantics.  It's closer to "flush the GL command stream, and in
> case we're rendering to the front buffer, pray that it will be updated soon,
> and without terrible tearing".

[snip[

> Instead of marking glXCopySubBufferMESA with CALL_FLAG_SWAPBUFFERS (which is
> incorrect, in doesn't swap the render target; see the definition at line 42),
> I'd suggest to invent a new flag, say, CALL_FLAG_FLUSH_CS, annotate glFlush,
> glFinish, glXCopySubBufferMESA with it, and ask the new flag to be or'ed into
> CALL_FLAG_SWAPBUFFERS.

ChromeOS is an interesting case. It *does* often use glXCopySubBufferMESA to mark end
of frame and request a buffer swap. ChromeOS has a spec-compliant implementation of
glXCopySubBufferMESA, but implements it by (usually) copying the *undamaged* rectangle from front
to back then swapping buffers.

ChromeOS is the odd one here, so I agree with Alexander that glXCopySubBufferMESA
should not be flagged with CALL_FLAG_SWAPBUFFERS. I just wanted to explain the
issue at hand.

The function *should* be annotated, though, since it is a critical frame divider
for ChromeOS. I'll defer to others the annotation should be.