[PATCH 0/6]

Pierre Willenbrock pierre at pirsoft.de
Mon Apr 27 14:26:58 PDT 2009


Ian Romanick schrieb:
> Pierre Willenbrock wrote:
> 
>>[...]
>> Additionally, in mesa, src/mesa/drivers/dri/intel/intel_tex_image.c,
>> intelSetTexBuffer2, color_rb[0](the front buffer) is accessed without
>> is_front_buffer_rendering being set to true, so RGBA visuals don't work
>> when doing opengl compositing.
> 
> This is what mesa-tex_image-front-buffer.patch is about?  I'm not sure I
> completely follow.  Could you elaborate?

Not all of mesa-tex_image-front-buffer.patch. I don't know if the
initialisation of is_front_buffer_rendering is needed, it seems to work
without.

In intelSetTexBuffer2 there is this sequence:

>    intel_update_renderbuffers(pDRICtx, dPriv);
> 
>    rb = intel_fb->color_rb[0];
>    /* If the region isn't set, then intel_update_renderbuffers was unable
>     * to get the buffers for the drawable.
>     */
>    if (rb->region == NULL)
>       return;

So, it expects intel_update_renderbuffers to fill the
intel_fb->color_rb[0]->region of the dPriv. This only happens, if
is_front_buffer_rendering is true(or if there is no back buffer). Maybe
something more complex is needed, forcing is_front_buffer_rendering to
true was the easiest way to get the region allocated.

>> Finally, i noticed that when forcing mesa to use DRI2GetBuffers, the
>> front buffer is requested without considering is_front_buffer_rendering.
>> In that case i get the "kwin renders to real front buffer" problem. This
>> also happens in the DRI2GetBuffersWithFormat-path, when using the
>> condition from the DRI2GetBuffers-path.
> 
> That's intentional and required.  With the DRI2GetBuffers path you have
> to request all of the attachments that might ever be used up-front.  If
> a second DRI2GetBuffers call is made and the size of the drawable hasn't
>  changed, it will just return the same set of buffers.  That is, it
> won't add the newly requested buffer at all.

Ah, okay. I just wanted to point out that there is still some problem
with applications getting the real front buffer, and that this depends
on when exactly the front buffer is requested.

>[...]


More information about the xorg-devel mailing list