[Mesa-dev] [PATCH 1/3] glx: remove glFlush call in glXSwapBuffers

Marek Olšák maraeo at gmail.com
Thu Nov 8 10:40:05 PST 2012


On Thu, Nov 8, 2012 at 3:04 PM, Michel Dänzer <michel at daenzer.net> wrote:
> On Don, 2012-11-08 at 14:48 +0100, Marek Olšák wrote:
>> Flushing here is unnecessary. The drivers which always flush in dri2Throttle
>> or __DRI2flushExtensionRec::flush are just wasting time here.
>>
>> st/mesa is updated to do what glFlush does.
>>
>> XXX I guess some other drivers should be updated to flush by themselves
>>     if they don't?
>> ---
>>  src/glx/glxcmds.c                    |    4 ----
>>  src/mesa/state_tracker/st_cb_flush.c |    1 +
>>  2 files changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
>> index 394bf59..22392bc 100644
>> --- a/src/glx/glxcmds.c
>> +++ b/src/glx/glxcmds.c
>> @@ -781,10 +781,6 @@ glXSwapBuffers(Display * dpy, GLXDrawable drawable)
>>        __GLXDRIdrawable *pdraw = GetGLXDRIDrawable(dpy, drawable);
>>
>>        if (pdraw != NULL) {
>> -         if (gc && drawable == gc->currentDrawable) {
>> -            glFlush();
>> -         }
>> -
>
> This behaviour is described rather explicitly in the GLX spec, so it
> seems kind of weird to remove this and then ensure the glXSwapBuffers
> semantics in non-GLX code. Would it be possible to eliminate the flushes
> in non-GLX code instead, or at least make them less expensive?

The GLX spec says glFlush should be performed, not that it must be
performed by explicitly calling "glFlush" inside libGL and before
dri2SwapBuffers. The problem is glFlush is the first flush here, not
the last one. If MSAA resolve or colorbuffer decompression had to be
done before SwapBuffers, we would want to do that *before* this
glFlush call. The glFlush call is completely useless if there still is
work to be done to finish the frame even if it's just creating the
fence for throttling, or worse, a complex MLAA resolve operation.

I'm open to suggestions how to resolve this flushing mess, but I don't
see any other way at the moment.

Marek


More information about the mesa-dev mailing list