[Mesa-dev] Mesa (master): intel: Update renderbuffers unconditionally in intelSetTexBuffer2()

[Kristian Høgsberg]

2010/5/5 Michel Dänzer <michel at daenzer.net>:
> On Die, 2010-05-04 at 10:36 -0700, Kristian HXXgsberg wrote:
>> Module: Mesa
>> Branch: master
>> Commit: 06c72da97a1bce87bc4b3fb8e7e18bf966926acb
>> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=06c72da97a1bce87bc4b3fb8e7e18bf966926acb
>>
>> Author: Kristian Høgsberg <krh at bitplanet.net>
>> Date:   Tue May  4 13:35:23 2010 -0400
>>
>> intel: Update renderbuffers unconditionally in intelSetTexBuffer2()
>>
>> ---
>>
>>  src/mesa/drivers/dri/intel/intel_tex_image.c |    3 +--
>>  1 files changed, 1 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c b/src/mesa/drivers/dri/intel/intel_tex_image.c
>> index 9db96ac..a0e734b 100644
>> --- a/src/mesa/drivers/dri/intel/intel_tex_image.c
>> +++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
>> @@ -728,8 +728,7 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
>>     if (!intelObj)
>>        return;
>>
>> -   if (dPriv->lastStamp != dPriv->dri2.stamp)
>> -      intel_update_renderbuffers(pDRICtx, dPriv);
>> +   intel_update_renderbuffers(pDRICtx, dPriv);
>
> This seems like a step in the wrong direction — doing a round-trip to
> the X server on each glXBindTexImageEXT() call kind of defeats the
> purpose of 'direct' rendering.

It was a temporary step towards correctness :)

> Of course, avoiding this only works correctly if the app calls
> glXWaitX() between receiving damage events (or itself doing X operations
> on the pixmap in question) and doing GL operations using the results,
> and if glXWaitX() actually guarantees that the X operations before it
> will be executed before the GL operations after it, which I don't think
> is the case yet with DRI2 (as it's a NOP in libGL when there's no fake
> front buffer).

glXWaitX() will only guarantee that whatever X rendering is queued up
on the display connection the GLX client uses is flushed and received
by the X server.  It doesn't guarantee anything about rendering from
other X clients, which in the case of TFP by a compositor is what
we're interested in.  If you want to synchronize rendering between
client and compositor you either need to grab the server (bad, simple
approach) or introduce a sync protocol between the compositor and
clients (better, compiz, gnome-shell, gtk+ support this as far as I
know).

But intel_update_renderbuffers() isn't about flushing or synchronizing
new content, it's about getting new buffers in case the window got
resized.  We can't really shortcut that without the DRI2 invalidate
event, but we have that now and I recently committed a few patches to
use that when available.

Kristian