On Thu, Nov 8, 2012 at 3:04 PM, Michel Dänzer <mic...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
