[PATCH 0/6]

[Pierre Willenbrock]

Ian Romanick schrieb:
> This patch set hits 4 repositories.  Woo-hoo!
> 
> The old DRI2GetBuffers protocol is replaced with DRI2GetBuffersWithFormat.
> This protocol adds a per-buffer format value.  This is a magic value that is
> opaque outside the driver.  The Intel driver simply sends the bits-per-pixel.
> Drivers with other requirements to make the correct allocation can send other
> data in the field.
> 
> The new function also behaves somewhat differently.  DRI2GetBuffers would
> create the requested set of buffers and destroy all previously existing
> buffers.  DRI2GetBuffersWithFormat creates the requested set of buffers, but
> it only destroys existing buffers on attachments in the requested set.
> Futher, it only allocates (or destroys) buffers if the size or format have
> changed.  This allows a client to initially request { DRI2BufferBackLeft,
> DRI2BufferDepth }, and later request { DRI2BufferBackLeft, DRI2BufferFrontLeft,
> DRI2BufferDepth } without ill effect.
> 
> Since the buffer allocation is done piece-wise, it is difficult to implement
> the combined depth / stencil buffers.  Taking a note from
> GL_ARB_framebuffer_object, I added a new DRI2BufferDepthStencil attachment.
> 
> I have tested the following combinations with the listed result:
> 
>  * New libGL, old 3D driver, old X server, old 2D driver -> works just as
>    previously
>  * New libGL, new 3D driver, old X server, old 2D driver -> works just as
>    previously
>  * New libGL, new 3D driver, new X server, old 2D driver -> DRI2 fails to
>    initialize, uses the software rasterizer
>  * New libGL, new 3D driver, old X server, new 2D driver -> DRI2 fails to
>    initialize, uses the software rasterizer
>  * New libGL, new 3D driver, new X server, new 2D driver -> Works the way
>    we really want it to!  Front-buffer rendering works, but the fake front-
>    buffer is only allocated when it's needed.  JUST LIKE MAGIC!
> 
> The combination that is not tested is the old libGL / 3D driver with everything
> else new.  This should work.  The idea is that if the the 2D driver receives
> format=0 in CreateBuffer, it should make the same allocation that CreateBuffers
> would have made for the attachment.

Looks like xf86-video-intel does not treat allocations with format=0 the
same with your patches. I need an extra (format !=
0)?format:pDraw->depth in xf86-video-intel to get kwin to work with a
mesa forced to use DRI2GetBuffers.

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.

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.

Completely unrelated to this(and your patchset): i think __glXDisp_WaitX
in xserver should call glxc->drawPriv->waitX instead of
glxc->drawPriv->waitGL.

Thanks for making opengl compositing using kwin work again on i965. I
attached patches for all of these problems, except for the differing
handling of is_front_buffer_rendering in intel_update_renderbuffers.

Regards,
  Pierre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mesa-tex_image-front-buffer.patch
Type: text/x-patch
Size: 1121 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20090425/23d6fdcb/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xf86-video-intel-format-default.patch
Type: text/x-patch
Size: 579 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20090425/23d6fdcb/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xserver-waitGL-waitX.patch
Type: text/x-patch
Size: 574 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20090425/23d6fdcb/attachment-0002.bin