2009/4/2 Ian Romanick <i...@freedesktop.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kristian Høgsberg wrote:
>> 2009/4/1 Ian Romanick <i...@freedesktop.org>:
>>> This is part of the fix for DRI2 front-buffer rendering.
>>>
>>> Signed-off-by: Ian Romanick <ian.d.roman...@intel.com>
>>> ---
>>> src/mesa/drivers/dri/intel/intel_context.c | 10 ++++++++--
>>> 1 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/intel/intel_context.c
>>> b/src/mesa/drivers/dri/intel/intel_context.c
>>> index 2e76e93..0aa1c18 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_context.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_context.c
>>> @@ -223,8 +223,10 @@ intel_update_renderbuffers(__DRIcontext *context,
>>> __DRIdrawable *drawable)
>>> screen = intel->intelScreen->driScrnPriv;
>>>
>>> i = 0;
>>> - if (intel_fb->color_rb[0])
>>> + if (intel_fb->color_rb[0]) {
>>> + attachments[i++] = __DRI_BUFFER_FAKE_FRONT_LEFT;
>>> attachments[i++] = __DRI_BUFFER_FRONT_LEFT;
>>> + }
>>
>> This will allocate an extra color buffer for double buffered rendering
>> where we don't need it. We need to ask for
>> __DRI_BUFFER_FAKE_FRONT_LEFT and __DRI_BUFFER_FRONT_LEFT when we're
>> single buffered and __DRI_BUFFER_FRONT_LEFT and __DRI_BUFFER_BACK_LEFT
>> when we're double buffered.
>
> So what happens when an application has a double buffered visual but is
> rendering to the front buffer? If I change glxgears to do a
> glDrawBuffer(GL_FRONT) during init and replace the glXSwapBuffers with
> glFlush, it should just work.
>
>>> if (intel_fb->color_rb[1])
>>> attachments[i++] = __DRI_BUFFER_BACK_LEFT;
>>> if (intel_get_renderbuffer(&intel_fb->Base, BUFFER_DEPTH))
>>> @@ -261,8 +263,12 @@ intel_update_renderbuffers(__DRIcontext *context,
>>> __DRIdrawable *drawable)
>>> for (i = 0; i < count; i++) {
>>> switch (buffers[i].attachment) {
>>> case __DRI_BUFFER_FRONT_LEFT:
>>> + rb = NULL;
>>> + break;
>>> +
>>> + case __DRI_BUFFER_FAKE_FRONT_LEFT:
>>> rb = intel_fb->color_rb[0];
>>> - region_name = "dri2 front buffer";
>>> + region_name = "dri2 fake front buffer";
>>> break;
>>
>> color_rb[0] should always correspond to __DRI_BUFFER_FRONT_LEFT so
>> GLX_tfp works. And uhm, I'm just realizing that we don't want the
>> fake front buffer for single buffered rendering to pixmaps (or
>> pbuffers), where we can render directly to the underlying pixmap. So
>> what I'm thinking is that we shouldn't ask for the fake frontbuffer in
>> the dri driver but handle it in the loader. The dri driver doesn't
>> know whether the drawable is a pixmap or a window, so it doesn't know
>> whether it should render the the real front or the fake front.
>>
>> So my suggestion is to handle this in glxdri2c:dri2GetBuffers(). If
>> the driver doesn't ask for a back buffer and we're rendering to a
>> window, ask the server for fake and real front buffers, store the real
>> front buffer data in the loader drawable private and pass the fake
>
> I think we always have to ask for the real and fake front buffers for
> windows. Other than that, those changes sound reasonable.
Ok, yes, glDrawBuffer(GL_FRONT) has to work, but always allocating an
extra color buffer that most apps won't ever use is not a good use of
memory. So what about this: for a double buffered visual, the dri
driver doesn't ask for the front at all, which the loader should
handle just fine. Then if the app wants to draw to the front buffer,
it will call getbuffers, but asking for the front buffer and not the
back buffer, that is, identical to the request it would issue for a
single buffered visual. And then it just works, since if the drawable
is a window, we'll ask for the fake front instead and pass that to the
driver. It wont be fast, but we're mostly concerned with correctnes
for front buffer rendering anyway.
cheers,
Kristian
------------------------------------------------------------------------------
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
