DRI2 RGB / RGBA visual problems [WAS: Re: intel 2.6.0: EXA choppy, UXA has artifacts]

[Peter Clifton]

On Sat, 2009-01-17 at 18:48 +0100, Khashayar Naderehvandi wrote:
> Hi!
> 
> I'm trying out the newly released intel driver on a X4500 chipset.
> The stack is composed of:
> 
> * kernel 2.6.28 with the patches from
> http://intellinuxgraphics.org/2008Q4.html applied
> * libdrm 2.4.4
> * mesa 7.3rc1
> * xorg-server 1.5.99.901.
> * intel driver 2.6.0
> 
> With EXA compiz becomes unusably choppy and slow. I don't know how to
> explain the behavior in a good way, but it's like everything is run
> through a stroboscope. Sort of.
> With UXA, on the other hand, everything's smooth and nice, but there
> are certain artifacts. Like this:
> http://dl.getdropbox.com/u/175461/uxa-artifacts.png.
> 
> Are these issues known? Any workarounds?

I think I've tracked the cause down, after a lot of searching. If you
hack the driver to disable DRI2, you'll notice the artifacts go away -
at the expense of various slow-downs.

The DRI GLX code in the X server clears the alpha channel to fully
opaque when binding a texture to a pixmap. It does this by wiping the
alpha contents after retrieving the image data. (Costly process)

DRI2 simply maps the texture in GL to the pixmap as is (as far as I can
tell), so Compiz is getting a texture which has its alpha channel set in
an undefined state (for RGB windows - RGBA ones are fine).

Interestingly, I found that rendering using cairo's OVER operator, with
a non-unity alpha seemed to somehow "reset" the (supposedly
non-existent) alpha channel for parts of a window drawn with that
operation.

I've attempted to find a work around for this in compiz, testing the
window for 24-bit depth when painting, and if so.. avoiding using the
texture's alpha channel. That fixes the window's compositing - it is
properly translucent, however the compiz decoration shadow on such a
window is broken (It ends up appearing black).

This seems (although its 4:40AM and I'm tired), that the decoration is
drawn with the same notional depth as the window causing the original
problem - 24bit, and thus triggers my new texture blending code -
causing it to ignore the alpha of the shadow.


Questions to those who might know..

Should DRI2 be clearing the Alpha channel (even if it requires making a
copy for these cases)?

Should compiz be decorating RGB windows using shadows which require
RGBA?

Is there some way to fake GL into thinking the non-copied texture from
DRI2 is in fact RGB, not RGBA, just with a stride of 4 bytes?


-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)

Thanks!


Peter Clifton  (a GL / DRI / DRI2 noob)!