DRI2: (UXA) white transparency artifacts with compiz [patch]

Confirming, since I've seen (and investigated) the same problem. Details on the cause to follow.

The problem is that UXA's texture from pixmap doesn't do anything special to override the alpha channel to unity for 24 bit colour depth pixmaps on the X server. (The old TFP implementations did).

Having discussed this a bit with the Intel guys, it seems the consensus is that the required information should be tracked in the FBConfig of the GLXPixmap created to represent the X pixmap being mapped as a texture.

Unfortunately, the Intel (mesa) driver doesn't currently expose any 24bit colour depth visuals / FBconfigs, so we end up mapping a 32 bit depth texture, with undefined alpha channel state.

Since GL / Compiz is using textures with pre-multiplied alpha, if the alpha channel is zero (for example), the arithmetic assumption is that the R,G and B components have already been multiplied by this number - giving a transparent window. The background contents are then summed in, whcih will very likely max out the R, G and B channels - hence the white images you're seeing rather than transaprency.

This effect is only seen whilst animations are attempting to adjust the opacity of the window.. in other cases, Compiz switches off the blending functions, and thus the alpha channel of the texture doesn't affect the display.

http://cgit.freedesktop.org/mesa/mesa/commit/?id=3ee21f30cda27e0ee1357f930163526622ba9434

and

http://cgit.freedesktop.org/mesa/mesa/commit/?id=24ff169486e315671c09cd8a57a311a935ccfff5

Seem like relevant upstream changes to expose more FBConfigs.

I haven't had time to try these out, to see if they "just work", with compiz picking the right visual -> correct texture format being selected etc..

As an alternative for Jaunty (if it were necessary), I've got a compiz patch (ABI breaking unfortunately) which avoids the issue by tracking the 24bit colour depth X pixmaps, and avoids using the alpha channel on their mapped textures.

Strictly speaking, this isn't a bug in the intel driver.. its a DRI2 problem. the Xorg server might also be relevant (since that is where DRI(1) works around this problem), but I think the fix will eventually land in Mesa.

With the above commits, an xserver fix is noted to be needed, as adding the 24 bit visuals exposed a bug in the mapping between GLXVisual and FBconfig:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=5100d829a4d71ce4a9fbc2b81694a1fb90066ccf

Added xorg-server source package, due to the above patch being necessary.. not sure if it should be in its own bug or not..

Confirmed, I'm seeing both behaviors on 965gm with compiz and UXA. While they are cosmetic, I also notice that images on some websites (e.g. cnn.com) are black (tfp issue?)

Peter, do you recommend we pull the two mesa patches listed above and carry them for jaunty in ubuntu?

Three, but combine the two for mesa - as they are just one fix..

They don't actually fix the problem, but we ought to start carrying the Xorg one anyway, otherwise you'll see breakage against newer mesa versions which have the upper two included.

I've not yet managed to come up with a satisfactory solution to the problem.. its pinged back to the mesa-devel list at the moment, awaiting some advice.

Basically, to do it "properly", I think I need to add a new hardware texture format in the core of mesa, which represents the XRGB8888 texture format (RGB888 but with a fourth byte unused).

There is probably another way around it though.. the old DRI(1) zero-copy TFP implementation hacked around the texture format issue with some override variables in the driver, which I could probably extend / replecate for the DRI2 case now the extra fbconfigs are exposed.

The other thing I need to check, is whether Compiz is actually picking 24 bit fbconfigs for 24bit depth windows. The code I read suggested that it ought to.. if they are available.

I'm not sure about cnn.com, that all renders fine on my GM45 box. Did you just see that behaviour under compiz?

I think it would be worth picking these up now, inspite them not actually fixing the problem, as it will help to isolate any possible regressions exposed by apps picking the wrong FBconfig amongst the new selection the patch will offer.

(The Xorg patch fixes a bug of that class which causes lots of breakage if not applied, since it ends up with broken GLXVisual -> FBConfig mapping for all GLX using applications.).

Just spotted your fix milestones... the Xorg server needs to be updated before / at the same time, as mesa.

The above patches are not necessaily regression free.. I already managed to break one of my own naievely coded GL apps with it, since it means that there are no visuals mis-reported with alpha bits where they shouldn't have them.

My app's unnecessary request to GtkGlExt for a visual with double-buffer _and_ alpha (not needed, since I'm not compositing), now fails, and the app didn't work...

Simple to patch in a fix, and since I'm a GL noob, not a mistake I expect to be widespread.. but still something we ought to get people testing sooner rather than later, in prep for the rest of the fix.

** Hold off on the patches for now, there is some upstream discussion as to whether they are correct or not, including an open bug report for the change causing problems (http://bugs.freedesktop.org/show_bug.cgi?id=19970).

I'm not sure if the Xorg patch is good or not.

UPDATE:

Eric Anholt has proposed a new Xorg patch which adds many more combinations of GLXVisuals and XVisuals, to avoid the breakage the above patches could cause to apps wanting a specific feature-set in their GLXVisual to do GL rendering. Lets wait to see what happens upstream on this one.

Quoting the patch's log message:

"""
[PATCH] glx: Replace broken GLX visual setup with a fixed "all" mode.

With trying to match depths so that you didn't end up with a depth 24
fbconfig for the 32-bit composite visual, I broke the alpha bits on the depth
24 X visual, which angered other applications. But in fixing that, the
pickFBconfigs code for "minimal" also could end up breaking GLX visuals if
the same FBconfig was chosen for more than one X visual.
We have no reason to not expose as many visuals as possible, but the old
"all" mode didn't match any existing X visuals to GLX visuals, so normal
GL apps didn't work at all.

Instead, replace it with a simple combination of the two modes: Create GLX
visuals by picking unique FBconfigs with as many features as possible for
each X visual in order. Then, for all remaining FBconfigs that are
appropriate for display, add a corresponding X and GLX visual.

This gets all applications (even ones that aren't smart enough to do FBconfigs)
get all the options to get the visual configuration they want. The only
potential downside is that the composite ARGB visual is unique and gets a
nearly full-featured GLX visual (except that the root visual might have taken
the tastiest FBconfig), which means that a dumb compositing manager could
waste resources. Write compositing managers using FBconfigs instead, please.
"""

Please someone assign this bug to you, or we'll remove the milestones.

I'm hesitant to do that, since I'm not sure if I've got time (or know-how) to fix it. Since UXA isn't going to be default in Jaunty, it probably isn't as important as was originally determined though.

At least with my GM965 [8086:2a02] is unusable slow with EXA (no matter if there is compiz activated), but totally snappy while UXA is activated (#303011). So UXA is of some importance...

Un-Milestoning, since UXA isn't the default. Please give a rationale and add an assignee if you want to milestone this.

since UXA solves somes bugs, maybe it should be the default ?
See for instance https://bugs.launchpad.net/netbook-remix-launcher/+bug/237731

UXA apparently also introduces some problems:

https://wiki.ubuntu.com/X/UxaTesting

However, it would be interesting to get the failure cases retested with the latest 2.6.3 intel driver, (and after verifying the Ubuntu kernel is using all the appropriate DRI kernel patches).

Asking in the wrong place, I know.. but I wonder if it would be possible to get UXA enabled by default based on the chipset involved. It would seem that most 965 and above chipsets improve with UXA/DRI2.

EXA in Intel 2.6.1 exposes some significant performance regressions (across all intel graphics chips as I understand). Running in UXA mode addresses this and increases performance further.

When this transparency issue is addressed and we move to intel-2.6.3 also, I feel making UXA default for newer graphics chipsets (or at least test for jaunty alpha 6) will be a profitable move, introducing minimal risk. I've been using UXA on my GM45 platform since 2.6.0 and EXA relatively jerky and slow.

There are other problems in uxa, such as that X crashes at resume
after suspend (I don't remember the bug link now)
If it is not resolved, moving to uxa will introduce problems

The "Session lost on resume from suspend bug": https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/322202.

I found a work around by Peter Clifton. It's a patch to compiz. I'm using it, everything's ok.

http://osdir.com/ml/ubuntu-x/2009-01/msg00026.html

Still repros on 2.6.29-rc8 + xorg-edgers as of today.

My repro steps:
1. start a gnome-terminal with "white text on black background" theme and run "ls -al" to fill it with some text.
2. do "gedit *.txt" on some files and use color theme "oblivion" (dark background).
3. repeatedly press the gedit taskbar entry to minimize/maximize gedit triggering the minimize/maximize animation in compiz. the white test from the gnome-terminal in the background cuts very clearly (opaque not blended at all) into the gedit window as it's gliding into maximized state. It's not until the maximize animation is completely finished that the opaque white text from the gnome-terminal in the background disappears.

A strange side note is that I no longer see the 1/10th of second white flash when opening the Applications menu in gnome-panel.

gksudo doesn't change/dim/shade the background though like it does on intrepid.

Three days ago I filed a bug about the gedit use case I described above:
https://bugs.freedesktop.org/show_bug.cgi?id=20707

A few hours ago Eric Anholt fixed that bug by commiting this upstream:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=66175aac7609ad314f25fbdff0d3958af310dc24

So now, using mesa master I get the correct behavior now all use cases:
A) opening the Applications menu does no longer flash a white thing for 1/10th second
B) gksudo correctly shades the background
C) the weird gedit minimize/maximize I described above now looks exactly like it should

Great! I'll test it.

On Fri, Mar 20, 2009 at 8:27 PM, martin <email address hidden> wrote:

> Three days ago I filed a bug about the gedit use case I described above:
> https://bugs.freedesktop.org/show_bug.cgi?id=20707
>
> A few hours ago Eric Anholt fixed that bug by commiting this upstream:
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=66175aac7609ad314f25fbdff0d3958af310dc24
>
> So now, using mesa master I get the correct behavior now all use cases:
> A) opening the Applications menu does no longer flash a white thing for
> 1/10th second
> B) gksudo correctly shades the background
> C) the weird gedit minimize/maximize I described above now looks exactly
> like it should
>
> --
> DRI2: (UXA) white transparency artifacts with compiz
> https://bugs.launchpad.net/bugs/324854
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Just updated and the problem is fixed for me.

I have uploaded a mesa 7.3-1ubuntu4~tormod to my PPA https://launchpad.net/~tormodvolden/+archive/ppa which is the plain Jaunty version with the addition of Eric Anholt's patch. Please check it out and verify that it fixes this issue.

@Tormod: yes it does.

Yes, these ppa packages seems to fix the issue completely. Are there any plans to include these fixes into official Ubuntu packages?

From what I heard, I think it's on the radar at least; but first they might merge mesa-7.4 (bugfix only release).

Yes, mesa 7.4 might get into Jaunty, but this patch was from the master branch and needs cherry-picking anyway.

I ve uploaded my xserver with the ppa restarted the xserver and i have to say it s not fixed for me... :-( I m still getting those white artefact

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
I have to say i ve got lots of regressions on 3d games without UXA enable..

The patch is for mesa, not for xserver.

On Sat, Mar 28, 2009 at 3:25 PM, taiebot65 <email address hidden> wrote:

> I ve uploaded my xserver with the ppa restarted the xserver and i have
> to say it s not fixed for me... :-( I m still getting those white
> artefact
>
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
> 943/940GML Express Integrated Graphics Controller (rev 03)
> I have to say i ve got lots of regressions on 3d games without UXA enable..
>
> --
> DRI2: (UXA) white transparency artifacts with compiz [patch]
> https://bugs.launchpad.net/bugs/324854
> You received this bug notification because you are a direct subscriber
> of the bug.
>

@taiebot65, portis, <others>: notice that yesterday a new mesa version was uploaded to Jaunty, fixing a mythtv problem. Because the package version is 7.3-1ubuntu4, the update will remove your custom-installed 7.3-1ubuntu4~tormod unless you pin the version in Synaptic or otherwise prevent the update. So with all the updates, the UXA problem will be back until the patch is uploaded to the official repositories.

This bug was fixed in the package mesa - 7.4-0ubuntu1

---------------
mesa (7.4-0ubuntu1) jaunty; urgency=low

  * New upstream release, merge from debian-experimental
    (LP: #330476, #347171, #349127)
  * Drop 103_rs600_support.patch, included in this version.
  * Drop 104_swrast_fbconfigs.patch, included in this version.
  * Add 103_bump_965_texture_limit.diff. (LP: #146298)
  * Add 104_fix_dri2_ext_tfp.diff. (LP: #324854)

 -- Timo Aaltonen <email address hidden> Fri, 03 Apr 2009 12:42:06 +0300

doesn't look like this would need changes in the xserver

can anyone confirm it works in mesa 7.4-0ubuntu1, just installed it, rebooted, and still doesn't work.
Is this the problem you people mean ?
Opacity 100% https://dl.getdropbox.com/u/871134/gedit1.png
Opacity 90% https://dl.getdropbox.com/u/871134/gedit2.png
Or should I open another bug ?

This bug still affects me. i915 chipset, up-to-date Jaunty with UXA enabled.
gksudo also does not shade the rest of the screen.

Ongion, if you do "dpkg -l | grep mesa" what does it priint?

Output is attached.

Well, at least you have the latest version of mesa (the same as I have) and the bug is supposed to be fixed in this version (and it certainly is fixed for me using that version). Have you ever built mesa from source on this machine? I'm thinking maybe you have some junk left in /usr/local or such?

No, I haven't built mesa from source before. I ran "ls -R /usr/local/ | grep -i mesa" just to be sure, and got no output. Do you know of anything else that might cause the problem?

I did fresh install on Jaunty and if i wasn't imagining things then i did this:
1.) X running in EXA (in default mode), alpha blending is correct, though compiz is bit sluggish, glxgears ~195fps (compiz vsync off)
2.) Added AccelMethod UXA to xorg.conf, init.d/gdm stop/start, alpha blending seemed correct, glxgear ~500fps,
installed extra plugins for compiz
Then for the night i shutdowned the laptop and in the morning UXA alpha blending was off again , glxgears ~320fps

openGL stuff throw:
get fences failed: -1
param: 6, val: 0

Tried the Tormod packages and compiled the Eric Anholt fix and still the same thing.
I'm using kernel 2.6.28 on Intepid with intel driver 2.6.3-0ubuntu.
I'm sure this bug isn't only related to mesa.

Can those currently affected by this problem specify what hardware they are running on? My card is:

$ lspci -nn | grep Graphics
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)

and it runs fine since mesa was patched.

I managed to find my cause, it is the fusion-icon.

Reproduce:
1.) install fusion-icon
2.) Set window manager to compiz
3.) Reload window manager

Appearently as fusion-icon starts at login, it forces compiz to reload.

Doing metacity --replace && compiz --replace , returns alpha blending to correct behaviour.

More correctly, it is compiz with --indirect-rendering

Yep, that solved my problem. For a fix, one could turn off the --indirect-rendering option in fusion-icon. Although I'm still curious as to why that causes a problem. Anyone have any thoughts?

Using GMA 950, with direct rendering i'm getting 3 or 4 spf (not a typo) which is equivalent to 0.3 fps. And with indirect rendering i'm getting the alpha blending problem. Anyway to fix both these problems ? How are you guys getting proper speeds with direct rendering ?

ok sorry guys. I seem to have this:
https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance#Problem: Huge performance drop with UXA due to tiled rendering disabled
Sorry for the inconvience...;)

Turning off indirect-rendering causes a memory leak in compiz.real. This is bug #328232.
Because this transparency problem seems to be continuing only due to indirect-rendering, I added this bug to compiz.

hi, im trying to patch mesa with the aforementioned patch, but for arch linux... it does build correctly, but the patch talks about upgrading the interfaces....whats that about? anyone got a clue? thanks

figured it out myself. thanks