Bug #270690 “[RV250] exa acclerated transparecy artifacts at can...” : Bugs : xserver-xorg-video-ati package : Ubuntu

wesley (mrthefter) on 2008-09-15

description:

updated

Revision history for this message

Bryce Harrington (bryce) wrote on 2008-10-01:

#1

Can you attach a photo or screenshot that shows the corruption? Also please attach your /var/log/Xorg.0.log and the output from lspci -vvnn. Thanks ahead of time.

Changed in xserver-xorg-video-ati:
status:	New → Incomplete

Revision history for this message

Bryce Harrington (bryce) wrote on 2008-10-01:

#2

Oh also your /etc/X11/xorg.conf as well.

Revision history for this message

wesley (mrthefter) wrote on 2008-10-03:

#3

Not on my linux machine at the moment (at work, and the machine is in standby, wireless internet no less, so no remote) so I can't get a screenshot. I will do it when I get back.

I can however, say that it's listed as a FireGL 9000 on spec sheets for my T40p Thinkpad, but shows as a RADEON Mobility 9000 [M9], an rv250 chipset.

As for xorg.conf, I can list off the changes I've made to it for the radeon driver, as I assume that's what you're looking for.
AGPMode 4x
DynamicClock on (tried off, too)
AccelMethod EXA
AccelDFS true (pretty sure I tried off)
ColorTiling off (tried on, too)
EnablePageFlip off (tried on, too)
VGAaccess false (i use radeonfb)
SubPixelOrder NONE (supposedly increases composite acceleration speed, according to man)
DMAforXv on
RenderAccel true

Anything not listed means it's at default. MigrationHeuristic defaults to either smart or always (not greedy, anyway) in the intrepid radeon drivers.
Anyway, like I said, setting RenderAccel to false, MigrationHeuristic to greedy, or AccelMethod to XAA will not produce the problem, because all of these use software RENDER.

I might also note that the transparency edge artifacts change every time the image updates. Easiest way to see results of this is to use cairo-dock with the zoom function (basically, like the mac osx dock when you mouseover). There'll be these white lines along random parts of the border of each element, and every time the image changes size (otherwise, updated) the lines will change position.

And finally, I hope this is obvious, but it only happens with a compositor. There wouldn't be accelerated transparency otherwise.

Revision history for this message

wesley (mrthefter) wrote on 2008-10-10:

#4

Alright, here's some screenshots.
The dock ones might not be noticeable, but the ClearWeather screenlet ones are very clear. Compare to SmoothWeather, right next to it, which doesn't have the problem.

Revision history for this message

wesley (mrthefter) wrote on 2008-10-10:

#5

Screenshot-1.png Edit (975.5 KiB, image/png)

Revision history for this message

wesley (mrthefter) wrote on 2008-10-10:

#6

screenshot.png Edit (137.9 KiB, image/png)

Bryce Harrington (bryce) on 2008-11-04

Changed in xserver-xorg-video-ati:
status:	Incomplete → Confirmed

Revision history for this message

In freedesktop.org Bugzilla #18401, Bryce Harrington (bryce) wrote on 2008-11-05:

#7

Forwarding this EXA bug from a Ubuntu tester:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/270690

[Problem]
White "boxes" appear around images when using Compiz under EXA.

[Original Report]
Using EXA RENDER acceleration in the open source radeon driver, on an rv250 (Mobility 9000), certain transparency elements will get artifacts along the border of the "canvas", for lack of a better word. It's not the border of the actual image, but the border of the entire canvas, i.e. a 32x32 image, of which the non-transparent image is only the center 16x16 square, the artifact would be along the "invisible" 32x32 edges.
The artifacts are consistent, in that it's always the same elements that have the problem.

Ubuntu Hardy Heron, 8.04
Xserver 1.4, Xorg 7.3
xserver-xorg-video-ati 6.8

The problem has existed since accelerated RENDER has been implemented. Still persists, even in the newer Intrepid Ibex 8.10 xserver and ati drivers.

Setting RenderAccel to false, or MigrationHeuristic to greedy makes the problem disappear, as this disables RENDER acceleration.

It doesn't seem to affect transparency that's generated by the compositor, but by transparency that's specified by an image.

[The chipset is] listed as a FireGL 9000 on spec sheets for my T40p Thinkpad, but shows as a RADEON Mobility 9000 [M9], an rv250 chipset.

As for xorg.conf, I can list off the changes I've made to it for the radeon driver:
AGPMode 4x
DynamicClock on (tried off, too)
AccelMethod EXA
AccelDFS true (pretty sure I tried off)
ColorTiling off (tried on, too)
EnablePageFlip off (tried on, too)
VGAaccess false (i use radeonfb)
SubPixelOrder NONE (supposedly increases composite acceleration speed, according to man)
DMAforXv on
RenderAccel true

Anything not listed means it's at default. MigrationHeuristic defaults to either smart or always (not greedy, anyway) in the intrepid radeon drivers.
Anyway, like I said, setting RenderAccel to false, MigrationHeuristic to greedy, or AccelMethod to XAA will not produce the problem, because all of these use software RENDER.

I might also note that the transparency edge artifacts change every time the image updates. Easiest way to see results of this is to use cairo-dock with the zoom function (basically, like the mac osx dock when you mouseover). There'll be these white lines along random parts of the border of each element, and every time the image changes size (otherwise, updated) the lines will change position.

And finally, I hope this is obvious, but it only happens with a compositor. There wouldn't be accelerated transparency otherwise.

[Screenshots]
http://launchpadlibrarian.net/18393667/Screenshot-1.png
http://launchpadlibrarian.net/18393751/screenshot.png