Catalyst 10.1 and Xorg 7.5 / 1.7.x?

[Erikina]

Are you both using the ForceLowPowerMode option with the UMS drivers ? If not, sounds like you should be...

I wasn't aware of its existence. I'll give it a try after it comes back from warranty

Thanks

[Kano]

Maybe you overrate what the fglrx "team" does. Most likely the shared code between Win+Linux is the part which supports new hardware not the Linux specific addons. So basically fglrx gets this part automatically as soon as there is a win driver.

[bridgman]

It doesn't do anything else than downclocking (last time I checked). Voltages stay at default values. Since only voltages matter with temps, downclocking doesn't do anything helpful. Temps stay the same if the voltage doesn't go down, no matter how much you downclock the card.

Have to disagree with you here. Leakage current won't go down without reducing voltages, but dynamic current goes down more-or-less linearly with clock speeds. If voltage is constant then power dissipation goes down in line with the total current.

As mirv said, if you are using ForceLowPowerMode and your temps are not going down that implies the fan controller is reducing fan speed, which in turn means your temps were probably in line with what the board vendor expected in the first place.

It could also mean the driver version on your system did not support ForceLowPowerMode, of course, but the logs will tell you what is happening there.

[HardBall]

Dude, you're stuck in 2008.

The free drivers are not perfect yet, but they provide OpenGL 2.0 on everything up to the HD 4xxx family. Only the latest 5xxx cards are still not supported.


I've been running these drivers for half a year and I assure you that I know that that means.

That means that everything I need works, including many games. I'm not much of a gamer, and there are games that still don't run well, but there is definitely working 3D, and it's more stable for me than nVidia's blob has ever been.


3D is an ongoing progression in the sense that not everything from the OpenGL 3.x spec is implemented. Most of the GL2 spec (which is what the vast majority of everything running on Linux actually uses) works great.

Power saving is a major issue. There is a load-based implementation available as a patch, but it will take a while before it becomes mainstream.

But that's really the last thing that the free drivers are missing.

Please don't spread FUD.

I would have to disagree. radeonhd doesn't have working 3D for many cards out there. Perhaps desktop models have better support. I have a Radeon 4850 that I even got working with xserver 1.6.4 and fglrx. But for mobile cards it's an entirely different story.

For my current laptop it's a Mobility Radeon 4830, which is displayed as M97 in xorg.conf. This is basically a low powered version of desktop rv740 (Radeon 4770) Which so far I have not been able to find a version of either fglrx or radeonhd that can enable 3d accel. This is after trying a variety of combinations of xservers (1.6.0 - 1.6.4), kernel versions (up to 2.6.33-rc3), and several distirbutions (Fedora 12, openSuse 11.2, Ubuntu 9.04/9.10/10.04alpha1).

Basically no version of either fglrx or radeonhd has provided any 3d accel (fglrx works with 9.04 with 1.6.0 marginally, but highly unstable) with any of these configurations. And since I need to do the bulk of my work on this system, and 3d is not a priority, I'm not spending any more time in trying to get a working config any more, until I hear something definitive.

If you know a version and a system config that would actually bring 3d accel, let me know; I'd be very glad to try it. But until then, from what I've observed, radeonhd doesn't actually have any better coverage of hardware than fglrx (as broken as it is with xserver 1.6) has at this moment. I'd be glad to try out any suggeestion that you might have.

[bridgman]

The radeon and radeonhd X drivers use the same 3D (mesa) and kernel (drm) drivers, so you should see more or less the same support with either X driver. The only difference would be that without kernel modesetting (implemented on radeon but not radeonhd) and the associated kernel memory manager you're only going to get GL 1.5 rather than GL 2-ish.

Have you tried using the drivers (radeon/drm) which ship with Fedora 12, only adding the "experimental" 3D mesa package ? If so, what happened with that combination ?

http://www.phoronix.com/scan.php?page=article&item=fedora_r600_3d&num=1

The 4770 family should be supported by both drivers (although IIRC there was a corruption issue with the open drivers which may not be resolved yet), so if your system isn't working with them it's likely to be a system-specific issue that the developers are not aware of. Probably worth filing a bug ticket in that case.

[Darksurf]

I would have to disagree. radeonhd doesn't have working 3D for many cards out there. Perhaps desktop models have better support. I have a Radeon 4850 that I even got working with xserver 1.6.4 and fglrx. But for mobile cards it's an entirely different story.

For my current laptop it's a Mobility Radeon 4830, which is displayed as M97 in xorg.conf. This is basically a low powered version of desktop rv740 (Radeon 4770) Which so far I have not been able to find a version of either fglrx or radeonhd that can enable 3d accel. This is after trying a variety of combinations of xservers (1.6.0 - 1.6.4), kernel versions (up to 2.6.33-rc3), and several distirbutions (Fedora 12, openSuse 11.2, Ubuntu 9.04/9.10/10.04alpha1).

Basically no version of either fglrx or radeonhd has provided any 3d accel (fglrx works with 9.04 with 1.6.0 marginally, but highly unstable) with any of these configurations. And since I need to do the bulk of my work on this system, and 3d is not a priority, I'm not spending any more time in trying to get a working config any more, until I hear something definitive.

If you know a version and a system config that would actually bring 3d accel, let me know; I'd be very glad to try it. But until then, from what I've observed, radeonhd doesn't actually have any better coverage of hardware than fglrx (as broken as it is with xserver 1.6) has at this moment. I'd be glad to try out any suggeestion that you might have.

Forgive me, but have you tried using Mesa 7.7 + Xorg 7.5 + 2.6.32 kernel + xf86-video-ati-9999 ? I'm getting great results. I'm using Sabayon Linux (gentoo based) have have added the x11 overlay and have been using the xf86-video-ati-9999 ebuild to stay on top of the git, and have found this combination to work better than I would have ever imagined! I'm sure the 2.6.23/24 kernel will be even better! Its crazy how well the drivers have progressed and cleaned up over time! I'm not sure why the last release is 6.12.4 though considering that its kinda an old release by now and they have a far better working version in git right now... I'm not ever going back to the fglrx drivers now.
(working on X200m (better than windoze),HD2600,HD3300,HD3870,HD4650) yeah, I know. I'm an ATI fanboy with too many ATI cards (and computers) and no Nvidia cards(except for my PS3 but that doesn't count).

[HardBall]

The radeon and radeonhd X drivers use the same 3D (mesa) and kernel (drm) drivers, so you should see more or less the same support with either X driver. The only difference would be that without kernel modesetting (implemented on radeon but not radeonhd) and the associated kernel memory manager you're only going to get GL 1.5 rather than GL 2-ish.

Have you tried using the drivers (radeon/drm) which ship with Fedora 12, only adding the "experimental" 3D mesa package ? If so, what happened with that combination ?

http://www.phoronix.com/scan.php?page=article&item=fedora_r600_3d&num=1

The 4770 family should be supported by both drivers (although IIRC there was a corruption issue with the open drivers which may not be resolved yet), so if your system isn't working with them it's likely to be a system-specific issue that the developers are not aware of. Probably worth filing a bug ticket in that case.

Thanks for the tips.

I'm not that familiar with current versions of Fedora. The last version of Fedora that I used on a regular basis was FC5, and the last few years I've mostly stuck to Debian/Ubuntu/Mint; so I'm a bit out of the loop of the RH world these days. The version was Fedora I used was I think with 2.6.31-16, xserver 1.6.3 or 1.6.4 (don't remember which one), KDE4.3; and the radeonhd was manually installed. I don't remember using the any experimental package. I will try that again in the near future; currently I don't have FC installed, I will do that and let you know.

I see that KMS definitely works with radeon driver for both FC12 and any version of Ubuntu with 2.6.31 or newer kernel. Although I haven't seen it working with radeonhd or fglrx yet. Paradoxically, it actually seems to work fine with fglrx for the desktop R4850, which is supposedly not supported by ATI.

I can confirm the graphics corruption issue. With gnome systems, it is a rare occurrence, only has to do with transparency and/or svg display, and often crops up after waking from sleep (acpi related). On KDE systems, it is much more severe, especially for openSuse11.2, the entire screen sometimes is corrupted and unusable.

The only system specific issue that I'm aware of is certain kernels (earlier ones are more problematic) does not mesh with the DSDT. The really early ones, like 2.6.24 refuses to boot at all. Kernels around 2.6.29 seems to use a workaround, and boots without certain acpi options (CPU p state), and as far as I can tell, 2.6.33 seems to have fixes, where those errors are gone from the boot process. But the issues with fglrx and radeonhd seem to be the same regardless of how compatible the kernel version with DSDT is; so I didn't think that would be likely the culprit. But I guess you never know.

If you or anyone else has other ideas, please let me know. I'll be glad to try and see what happens.

[HardBall]

Forgive me, but have you tried using Mesa 7.7 + Xorg 7.5 + 2.6.32 kernel + xf86-video-ati-9999 ? I'm getting great results. I'm using Sabayon Linux (gentoo based) have have added the x11 overlay and have been using the xf86-video-ati-9999 ebuild to stay on top of the git, and have found this combination to work better than I would have ever imagined! I'm sure the 2.6.23/24 kernel will be even better! Its crazy how well the drivers have progressed and cleaned up over time! I'm not sure why the last release is 6.12.4 though considering that its kinda an old release by now and they have a far better working version in git right now... I'm not ever going back to the fglrx drivers now.
(working on X200m (better than windoze),HD2600,HD3300,HD3870,HD4650) yeah, I know. I'm an ATI fanboy with too many ATI cards (and computers) and no Nvidia cards(except for my PS3 but that doesn't count).

I will certainly try that combo as well.

Which distro and desktop env are you using? And any chance this would work with 2.6.33 as well?

[HardBall]

bridgman, Thanks for the tips.

I'm not that familiar with current versions of Fedora. The last version of Fedora that I used on a regular basis was FC5, and the last few years I've mostly stuck to Debian/Ubuntu/Mint; so I'm a bit out of the loop of the RH world these days. The version was Fedora I used was I think with 2.6.31-16, xserver 1.6.3 or 1.6.4 (don't remember which one), KDE4.3; and the radeonhd was manually installed. I don't remember using the any experimental package. I will try that again in the near future; currently I don't have FC installed, I will do that and let you know.

I see that KMS definitely works with radeon driver for both FC12 and any version of Ubuntu with 2.6.31 or newer kernel. Although I haven't seen it working with radeonhd or fglrx yet. Paradoxically, it actually seems to work fine with fglrx for the desktop R4850, which is supposedly not supported by ATI.

I can confirm the graphics corruption issue. With gnome systems, it is a rare occurrence, only has to do with transparency and/or svg display, and often crops up after waking from sleep (acpi related). On KDE systems, it is much more severe, especially for openSuse11.2, the entire screen sometimes is corrupted and unusable.

The only system specific issue that I'm aware of is certain kernels (earlier ones are more problematic) does not mesh with the DSDT. The really early ones, like 2.6.24 refuses to boot at all. Kernels around 2.6.29 seems to use a workaround, and boots without certain acpi options (CPU p state), and as far as I can tell, 2.6.33 seems to have fixes, where those errors are gone from the boot process. But the issues with fglrx and radeonhd seem to be the same regardless of how compatible the kernel version with DSDT is; so I didn't think that would be likely the culprit. But I guess you never know.

If you or anyone else has other ideas, please let me know. I'll be glad to try and see what happens.

[Darksurf]

I will certainly try that combo as well.

Which distro and desktop env are you using? And any chance this would work with 2.6.33 as well?

I use Sabayon Linux 5.1 x86_64 KDE4 (based off gentoo so it can use portage AND our binary package manager entropy)

I'm pretty sure this should work with 2.6.33 considering the last update for the kernel (rc4) was 40% improvements on DRM for the radeon and intel module.