DRI2 RGB / RGBA visual problems [WAS: Re: intel 2.6.0: EXA choppy, UXA has artifacts]
pcjc2 at cam.ac.uk
Tue Jan 20 20:45:50 PST 2009
On Sat, 2009-01-17 at 18:48 +0100, Khashayar Naderehvandi wrote:
> 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 126.96.36.1991.
> * 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:
> 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
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
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?
Electrical Engineering Division,
University of Cambridge,
9, JJ Thomson Avenue,
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Peter Clifton (a GL / DRI / DRI2 noob)!
More information about the xorg