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

Bug #324854 reported by Nicolò Chieffo
86
This bug affects 10 people
Affects Status Importance Assigned to Milestone
mesa (Ubuntu)
Fix Released
High
Unassigned
xorg-server (Ubuntu)
Invalid
High
Unassigned
xserver-xorg-video-intel (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-intel

2:2.6.1-1ubuntu1

there are compiz issues when runining intel with UXA acceleration method:
- when creating popup windows (the menu items) the background is for 1/10 s white and yellow
- when running gksudo the screen does not become gray

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: xserver-xorg-video-intel 2:2.6.1-1ubuntu1
ProcEnviron:
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
ProcVersion: Linux version 2.6.28-6-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-3ubuntu1) ) #17-Ubuntu SMP Fri Jan 30 15:34:36 UTC 2009

SourcePackage: xserver-xorg-video-intel
Uname: Linux 2.6.28-6-generic i686

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
     Subsystem: Dell Device [1028:0233]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
     Subsystem: Dell Device [1028:0233]

Tags: apport-bug

Related branches

Revision history for this message
Nicolò Chieffo (yelo3) wrote :
Revision history for this message
Peter Clifton (pcjc2) wrote :

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

Changed in xserver-xorg-video-intel:
status: New → Confirmed
Revision history for this message
Peter Clifton (pcjc2) wrote :

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.

Revision history for this message
Peter Clifton (pcjc2) wrote :

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.

Changed in mesa:
status: New → Confirmed
Revision history for this message
Peter Clifton (pcjc2) wrote : Re: DRI2: (UXA) artifacts with compiz

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.

Changed in xserver-xorg-video-intel:
status: Confirmed → Invalid
Bryce Harrington (bryce)
Changed in mesa:
importance: Undecided → High
status: Confirmed → Triaged
Revision history for this message
Peter Clifton (pcjc2) wrote : Re: DRI2: (UXA) white transparency artifacts with compiz

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

Revision history for this message
Peter Clifton (pcjc2) wrote :

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

Revision history for this message
Bryce Harrington (bryce) wrote :

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?

Changed in xorg-server:
importance: Undecided → High
milestone: none → jaunty-alpha-6
status: New → Triaged
Changed in mesa:
milestone: none → jaunty-alpha-5
Revision history for this message
Peter Clifton (pcjc2) wrote :

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?

Revision history for this message
Peter Clifton (pcjc2) wrote :

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.).

Revision history for this message
Peter Clifton (pcjc2) wrote :

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

Revision history for this message
Peter Clifton (pcjc2) wrote :

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.

Revision history for this message
Peter Clifton (pcjc2) wrote :

** 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.

Revision history for this message
Peter Clifton (pcjc2) wrote :

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.
"""

Revision history for this message
Martin Pitt (pitti) wrote :

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

Revision history for this message
Peter Clifton (pcjc2) wrote :

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.

Revision history for this message
Matthias Blaicher (blaicher) wrote :

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...

Bryce Harrington (bryce)
description: updated
Revision history for this message
Martin Pitt (pitti) wrote :

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

Changed in xorg-server:
milestone: jaunty-alpha-6 → none
Changed in mesa:
milestone: jaunty-alpha-5 → none
Revision history for this message
antistress (antistress) wrote :

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

Revision history for this message
Peter Clifton (pcjc2) wrote :

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.

Revision history for this message
Daniel J Blueman (danielblueman) wrote :

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.

Revision history for this message
Nicolò Chieffo (yelo3) wrote : Re: [Bug 324854] Re: DRI2: (UXA) white transparency artifacts with compiz

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

Revision history for this message
Matteo Collina (matteo-collina) wrote : Re: DRI2: (UXA) white transparency artifacts with compiz
Revision history for this message
Mingming Ren (portis25) wrote :

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

Revision history for this message
Martin Olsson (mnemo) wrote :

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.

Revision history for this message
Martin Olsson (mnemo) 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

Revision history for this message
portis (portis24) wrote : Re: [Bug 324854] Re: DRI2: (UXA) white transparency artifacts with compiz

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.
>

Revision history for this message
Pascal Will (luciensan) wrote : Re: DRI2: (UXA) white transparency artifacts with compiz

Just updated and the problem is fixed for me.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

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.

Revision history for this message
pablomme (pablomme) wrote :

@Tormod: yes it does.

Revision history for this message
Ivan Stetsenko (stetzen) wrote :

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

Revision history for this message
Martin Olsson (mnemo) wrote :

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

Revision history for this message
Tormod Volden (tormodvolden) wrote :

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

summary: - DRI2: (UXA) white transparency artifacts with compiz
+ DRI2: (UXA) white transparency artifacts with compiz [patch]
Revision history for this message
taiebot65 (taiebot65) 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..

Revision history for this message
portis (portis24) wrote : Re: [Bug 324854] Re: DRI2: (UXA) white transparency artifacts with compiz [patch]

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.
>

Revision history for this message
pablomme (pablomme) wrote :

@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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in mesa (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

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

Changed in xorg-server (Ubuntu):
status: Triaged → Invalid
Revision history for this message
George Stephanos (gaf-stephanos) wrote :

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 ?

Revision history for this message
Ongion (benpy2k) wrote :

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

Revision history for this message
Martin Olsson (mnemo) wrote :

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

Revision history for this message
Ongion (benpy2k) wrote :

Output is attached.

Revision history for this message
Martin Olsson (mnemo) wrote :

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?

Revision history for this message
Ongion (benpy2k) wrote :

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?

Revision history for this message
FurYy (jack-un) wrote :

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

Revision history for this message
George Stephanos (gaf-stephanos) wrote :

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.

Revision history for this message
pablomme (pablomme) wrote :

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.

Revision history for this message
FurYy (jack-un) wrote :

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.

Revision history for this message
FurYy (jack-un) wrote :

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

Revision history for this message
Ongion (benpy2k) wrote :

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?

Revision history for this message
George Stephanos (gaf-stephanos) wrote :

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 ?

Revision history for this message
George Stephanos (gaf-stephanos) wrote :

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...;)

Revision history for this message
Ongion (benpy2k) wrote :

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.

Changed in compiz:
status: Unknown → Confirmed
Revision history for this message
Tomas M. (el-dragon) wrote :

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

Revision history for this message
Tomas M. (el-dragon) wrote :

figured it out myself. thanks

no longer affects: compiz
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.