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)! _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
