[R100 Mobility M7 7500] Problems with 16bit mode using radeon driver

[Jonathan Jogenfors]

Binary package hint: xorg

I'm using a Thinkpad T30 with a builtin Radeon Mobility M7 LW [Radeon Mobility 7500] card. When upgrading to the Intrepid release candidate, almost everything worked except compiz. There were apparently no borders, and there were several graphical glitches. For instance, gnome-terminal was all white.

I'm using the radeon open source driver which has worked flawlessly in Hardy.

Tracking the problem, compiz --replace gave the following:

/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x30005f1 to texture

That message repeated forever.

This happened in 16bit color depth, 1024x768. When I tried 24bit, there were no visual problems anymore, only everything running really, really slow. My card has only 16 MiB of VRAM, so the probable explanation there is that compiz can't handle the textures at that color depth. 800x600x24 worked, but I would rather use metacity than a 800x600 compiz.

In the #compiz IRC channel, I together with a few compiz developers successfully confirmed the bug on a Gentoo machine running Xorg 6.9.0 and a similar card, though with 32MB of ram.

The conclusion we came to is that between Hardy and Intrepid there has been a regression in the radeon driver that borked the 16bit mode. This wouldn't be a problem for people running cards with more memory than 16MB since they can switch to 24bit depth.

The bug also exists in the exact same form on the latest LiveCD.

Steps to reproduce:
1. Use a Radeon Mobility M7 LW [Radeon Mobility 7500] with 16 MB of VRAM
2. Switch to 16 bit mode (24bit is the default)
3. Restart X

This bug is important since it affects -all- owners of Thinkpad T30 laptops, as well as other owners of the M7 card.
[lspci]
00:00.0 Host bridge: Intel Corporation 82845 845 [Brookdale] Chipset Host Bridge (rev 04)
     Subsystem: IBM Device 0220
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]
     Subsystem: IBM Device 0517

[Bryce Harrington (bryce)]

Hmm, next I'd like to forward this issue upstream, but first it must be retested on latest Jaunty to make sure the issue still happens there with the latest code. ISO images are available at http://cdimages.ubuntu.com/releases/jaunty/. If you can reproduce it in the LiveCD environment, you shouldn't need to modify your installed system. Also please attach a fresh Xorg.0.log from this testing.

[Jonathan Jogenfors (etnoy)]

@Bryce:

Okay, I'll test the Jaunty CD:s. However, I am pretty sure the card is an r100 card and not rv200 one.

Jonathan

[Jonathan Jogenfors (etnoy)]

The bug still exists in jaunty alpha.

This is the logfile for the most recent alpha release. Note that I manually had to change to 16-bit depth for compiz to even start. With 24-bit depth compiz fails some checks and reverts to metacity.

[Jonathan Jogenfors (etnoy)]

OK if I remove the incomplete status?

[Bryce Harrington (bryce)]

Created an attachment (id=23556)
Xorg.0.log from Jaunty, with 6.11.0 -ati

[Problem]
Compiz exhibits problems running on this R100 card, including graphical glitches, no borders, etc.

This is a regression since Hardy, where -ati 6.8.0 worked properly, and 6.9.0 when the problem first began. It is still seen with the 6.10.x and 6.11.0 drivers.

[lspci]
00:00.0 Host bridge: Intel Corporation 82845 845 [Brookdale] Chipset Host Bridge (rev 04)
     Subsystem: IBM Device 0220
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]
     Subsystem: IBM Device 0517

[Original Report]
I'm using a Thinkpad T30 with a builtin Radeon Mobility M7 LW [Radeon Mobility 7500] card. When upgrading to the Intrepid release candidate, almost everything worked except compiz. There were apparently no borders, and there were several graphical glitches. For instance, gnome-terminal was all white.

I'm using the radeon open source driver which has worked flawlessly in Hardy.

Tracking the problem, compiz --replace gave the following:

/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x30005f1 to texture

That message repeated forever.

This happened in 16bit color depth, 1024x768. When I tried 24bit, there were no visual problems anymore, only everything running really, really slow. My card has only 16 MiB of VRAM, so the probable explanation there is that compiz can't handle the textures at that color depth. 800x600x24 worked, but I would rather use metacity than a 800x600 compiz.

In the #compiz IRC channel, I together with a few compiz developers successfully confirmed the bug on a Gentoo machine running Xorg 6.9.0 and a similar card, though with 32MB of ram.

The conclusion we came to is that between Hardy and Intrepid there has been a regression in the radeon driver that borked the 16bit mode. This wouldn't be a problem for people running cards with more memory than 16MB since they can switch to 24bit depth.

The bug also exists in the exact same form on the latest LiveCD.

Steps to reproduce:
1. Use a Radeon Mobility M7 LW [Radeon Mobility 7500] with 16 MB of VRAM
2. Switch to 16 bit mode (24bit is the default)
3. Restart X

This bug is important since it affects -all- owners of Thinkpad T30 laptops, as well as other owners of the M7 card.

The bug still exists in jaunty alpha.

This is the logfile for the most recent alpha release. Note that I manually had to change to 16-bit depth for compiz to even start. With 24-bit depth compiz fails some checks and reverts to metacity.

[Bryce Harrington (bryce)]

Created an attachment (id=23557)
glxinfo

[Bryce Harrington (bryce)]

Output from running `compiz --replace`:

Checking for Xgl: not present.
Detected PCI ID for VGA:
Checking for texture_from_pixmap: not present.
Trying again with indirect rendering:
Checking for texture_from_pixmap: present.
Checking for non power of two support: present.
Checking for Composite extension: present.
Comparing resolution (1024x768) to maximum 3D texture size (2048): Passed.
Checking for Software Rasterizer: Not present.
Checking for nVidia: not present.
Checking for FBConfig: present.
Checking for Xgl: not present.
/usr/bin/compiz.real (core) - Warn: SmcOpenConnection failed: Could not open network socket
/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (resizeinfo) - Warn: Bind Pixmap to Texture failure
/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (resizeinfo) - Warn: Bind Pixmap to Texture failure
/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (wall) - Error: Couldn't create cairo context for switcher
/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (wall) - Error: Couldn't create cairo context for switcher
/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (wall) - Error: Couldn't create cairo context for switcher
/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (wall) - Error: Couldn't create cairo context for switcher
/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x1800046 to texture

/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x30005f1 to texture

/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x1800046 to texture

/usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
/usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x30005f1 to texture

The last two messages repeat forever.

[Michel Dänzer (michel-daenzer)]

Created an attachment (id=23562)
Possible fix

Does this patch fix the problem?

[Jonathan Jogenfors (etnoy)]

Michel:

I would love to test the patch (I'm the original launchpad reporter), is there a good way to test this under Ubuntu Intrepid?

Jonathan

[agd5f (agd5f)]

(In reply to comment #4)
> Michel:
>
> I would love to test the patch (I'm the original launchpad reporter), is there
> a good way to test this under Ubuntu Intrepid?

you can follow my instructions here:
http://www.botchco.com/agd5f/?page_id=2
before you build, apply the patch:
patch -p1 -i radeon-depth16-aiglx.diff

[Bryce Harrington (bryce)]

The bug has been forwarded upstream to https://bugs.freedesktop.org/show_bug.cgi?id=20479 - please subscribe to this bug in case upstream needs more info or wishes you to test something. Thanks ahead of time.

[Bryce Harrington (bryce)]

I've built debs with this patch here:
http://people.ubuntu.com/~bryce/Testing/ati-bug290359/

[Jonathan Jogenfors (etnoy)]

Okay. I downloaded the drivers from git, applied the patch, compiled and installed. Then I tried everything, even rebooting, but even then I saw no change. The exact symptoms remain.

Jonathan

[aneiser (andreas-neiser)]

Hej,
I'm experiencing this problem, too, and can confirm that the "Possible fix" DOES NOT help. In 16bit, still getting the

Warn: No GLXFBConfig for depth 32

when running fusion-icon and switching to compiz with the help of that. No further error messages, but window decorations are completely missing (although some fading effects seem to work).

While using 24bit, everything runs fine, but performance is really slow :(

I'm using ArchLinux and compiled xf86-video-ati-git with the proposed patch (and of course installed it after removing xf86-video-ati and ati-dri).

My card (lspci output):
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02)

So, is there anything I can test/patch/provide so you can try to fix this issue? By the way, for me this is a regression, too, since Compiz used to work with 16bit and acceptable performance.

[agd5f (agd5f)]

Created an attachment (id=23726)
add double buffered 32 bit visual

Maybe compiz wants a double buffered visual. Does this patch help?

[aneiser (andreas-neiser)]

Nope, the second patch did not help, unfortunately. By the way, I found out that using 24bit improves watching youtube videos with the non-free flash plugin. So I'm torn between 16bit and 24bit ;)

[agd5f (agd5f)]

What xservers did you use with 6.8.0 vs. 6.9.0+? I think it is probably related to aiglx changes in X rather than the driver since the visual setup code in the driver hasn't changed between 6.8.0 and newer versions.

[aneiser (andreas-neiser)]

Yes, that's possile. Unfortunately I did not track the compiz regression since I have not been using compiz for that time. But I remember the last time I used compiz was before the upgrade to X 1.6.x (the HAL stuff is a good memory aid;)
So, is there any way to debug this without recompiling like hell ;)

[agd5f (agd5f)]

(In reply to comment #12)
> Yes, that's possile. Unfortunately I did not track the compiz regression since
> I have not been using compiz for that time. But I remember the last time I used
> compiz was before the upgrade to X 1.6.x (the HAL stuff is a good memory aid;)
> So, is there any way to debug this without recompiling like hell ;)
>

If your distro provides older xserver packages you could try those.

[aneiser (andreas-neiser)]

(OT: How can I quote some comments?)
Well, it does not really (excepte recompiling the old packages and when I'm thinking of the changes from 1.5->1.6...), I'm using ArchLinux... Is there any other way?

[Jonathan Jogenfors (etnoy)]

From what I have deduced by asking around in irc channels (specifically, #compiz, #ati and #radeon) the problem is in the GLX code in Xorg and not in the ati drivers. I was told to talk to Kristian Hoengsberg, xorg glx developer, but haven't done so yet.

Phew, I miss compiz right now, haven't been able to use it for the past four-five months...

[Michel Dänzer (michel-daenzer)]

Created an attachment (id=24209)
Likely fix

This Mesa patch seems to fix the problem here. Can you confirm?

[Carcaussa (carcaussa)]

I applied the patch and compiled the library, and noticed a change from the previous symptoms, but is not working, now I have window decorations but everything else, including desktop, is white. I tried reducing the screen resolution and didn't help, also rebooted the computer.

[Michel Dänzer (michel-daenzer)]

(In reply to comment #17)
> I applied the patch and compiled the library, and noticed a change from the
> previous symptoms, but is not working, now I have window decorations but
> everything else, including desktop, is white.

Do you still get any messages from compiz, e.g. about not being able to bind windows to textures?

[Jonathan Jogenfors (etnoy)]

Which version of Mesa should the patch be used against? I tried the latest dev version, but that one won't compile (unrelated error)

Jonathan

[Michel Dänzer (michel-daenzer)]

(In reply to comment #19)
> Which version of Mesa should the patch be used against?

I created it against mesa Git master.

> I tried the latest dev version, but that one won't compile (unrelated error)

What's the 'latest dev version' you're referring to? What's the error? Does the patch not apply to the version of Mesa you're using?

[Jonathan Jogenfors (etnoy)]

Mesa-7.5-devel-20090313 was the version I used. This is the relevant part of the error:

make[5]: Entering directory `snip/Mesa-7.5-devel-20090313/src/gallium/winsys/drm/intel/gem'
make[5]: *** No rule to make target `default'. Stop.

I got the download from here: http://www.mesa3d.org/beta/

Now I just found the git version as well, was really not obvious that there was one :) I will try compiling again.

[Michel Dänzer (michel-daenzer)]

(In reply to comment #21)
> make[5]: Entering directory
> `snip/Mesa-7.5-devel-20090313/src/gallium/winsys/drm/intel/gem'
> make[5]: *** No rule to make target `default'. Stop.

FWIW you don't need to build any Gallium stuff for this, try something like

make GALLIUM_DIRS=''

as a quick workaround.

[Carcaussa (carcaussa)]

Hi I am compiling against version 7.2 that comes with ubuntu intrepid, I had to manually apply the patch because this specific version was reporting a parameter count error and an undefined msaa_samples_array, which is part of the extra parameters that I had to remove, according to the current definition of driCreateConfigs,

Instances like:
driCreateConfigs(GL_RGB, GL_UNSIGNED_SHORT_5_6_5,
     depth_bits_array, stencil_bits_array,
     depth_buffer_factor, back_buffer_modes,
     back_buffer_factor, msaa_samples_array,
     1);
became:
driCreateConfigs(GL_RGB, GL_UNSIGNED_SHORT_5_6_5,
     depth_bits_array, stencil_bits_array,
     depth_buffer_factor, back_buffer_modes,
     back_buffer_factor);

to match the current definition.

compiled ok and I am not receiving the texture error anymore, instead I am receving the following warning:

/usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format

could this be the root cause?

[Michel Dänzer (michel-daenzer)]

(In reply to comment #23)
> /usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12
> image format
>
> could this be the root cause?

No, that's a harmless warning from the compiz video plugin, which you probably don't need anyway.

[Michel Dänzer (michel-daenzer)]

Omar, can you attach the glxinfo output with and without the patch applied?

[Carcaussa (carcaussa)]

Created an attachment (id=24302)
glxinfo with the original distribution libraries

[Carcaussa (carcaussa)]

Created an attachment (id=24303)
glxinfo with the opatched and rebuilt libraries

glxinfo output added

[Michel Dänzer (michel-daenzer)]

Maybe there were more issues in Mesa 7.2... can you try the patch with 7.4?

[Carcaussa (carcaussa)]

I'm sorry, I don't have the environment to fulfill all the dependencies to build mesa 4, not sure if someone else can give it a try

[Carcaussa (carcaussa)]

Installed jaunty beta, to confirm that the error was still present in Mesa 7.4, applied the patch with same previous modifications and can confirm that the patch works, applying the tailored version of the patch solved the issue

[Michel Dänzer (michel-daenzer)]

Fixed in mesa Git and cherry-picked to the 7.4 branch, thanks for testing.

[Jonathan Jogenfors (etnoy)]

Created an attachment (id=24596)
glxinfo with latest mesa git per 04/06/2009

I downloaded the latest git, compiled and installed. For me the bug stils persists. The attached glxinfo shows that I'm using the mesa devel version.
How can I make sure that I really am using the mesa version that I installed?

Bottom line: Bug isn't fixed as far as I can see

Jonathan

[Michel Dänzer (michel-daenzer)]

(In reply to comment #32)
> I downloaded the latest git, compiled and installed. For me the bug stils
> persists. The attached glxinfo shows that I'm using the mesa devel version.
> How can I make sure that I really am using the mesa version that I installed?

grep _dri /var/log/Xorg.0.log

Did you restart X after installing the self-compiled radeon_dri.so?

[Jonathan Jogenfors (etnoy)]

I just verified /usr/lib/dri/radeon_dri.so with the ./lib/radeon_dri.so in the freshly compiled git tree with md5sum and they match. Yes, I restarted X.
I also checked the source code I compiled and saw that the patch has indeed been applied to my source tree.

Very strange indeed as the patch fixes the problem for Omar Servin but not for me. I'm running out of ideas...

Jonathan

[agd5f (agd5f)]

(In reply to comment #34)
> I just verified /usr/lib/dri/radeon_dri.so with the ./lib/radeon_dri.so in the
> freshly compiled git tree with md5sum and they match. Yes, I restarted X.
> I also checked the source code I compiled and saw that the patch has indeed
> been applied to my source tree.
>

Is the xserver successfully loading the new 3D driver for AIGLX?

[Jonathan Jogenfors (etnoy)]

Created an attachment (id=24604)
Xorg log

Yes, as far as I can see AIGLX successfully loads radeon_dri (I attached Xorg.log just to be sure)

Sorry for spamming bugzilla with my silly questions.

Jonathan

[Michel Dänzer (michel-daenzer)]

(In reply to comment #34)
> Very strange indeed as the patch fixes the problem for Omar Servin but not for
> me. I'm running out of ideas...

Are you both running the same version of the X server? I suspect there might have been something else preventing this from working in 1.5...

[Carcaussa (carcaussa)]

My current versions:
Server version:
X.Org X Server 1.6.0
Release Date: 2009-2-25
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-23-server i686 Ubuntu

Radeon driver version:
(II) Module radeon: vendor="X.Org Foundation"
 compiled for 1.6.0, module version = 6.12.1
 Module class: X.Org Video Driver
 ABI class: X.Org Video Driver, version 5.0

[Jonathan Jogenfors (etnoy)]

X.Org X Server 1.5.2
Release Date: 10 October 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-24-xen i686 Ubuntu
Current Operating System: Linux bordslykta 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686
Build Date: 26 March 2009 03:47:28PM
xorg-server 2:1.5.2-2ubuntu3.1+ppa2 (<email address hidden>)

This is using Ubuntu Intrepid. I will try the Ubuntu Jaunty betas as soon as I get home from my vacation, will be afk for more than one week starting today.

Jonathan

[Jonathan Jogenfors (etnoy)]

I'm setting this to fixed