X.Org ATI Driver Supports New Power Options

[shawjames36]

Latest news about the X.org.

26 May 2011: 6.14.2: Cayman (Radeon HD 6900) acceleration support, Fusion APU tiling fixes, other fixes [ changelog ]

17 Mar 2011: 6.14.1: Cayman (Radeon HD 6900) support (shadowfb, kms-only), big endian support [ changelog ]

3 Feb 2011: 6.14.0: KMS EXA/Xv support for Evergreen GPUs (Radeon HD 5000 series), Fusion APUs (Ontario series) and Northern Islands GPUs (Radeon HD 6000 series but not 6900), KMS pageflipping support for all radeons [ changelog ]

6 Jul 2010: 6.13.1: server 1.9 support, evergreen accel disabled explicitly, kms uevent + sync support, rn50 fixes, enable color tiling on kms on r300->r500. xv cleanup and large vertex number fixes. [ changelog ]

Latest changes in the development tree can be seen at: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/


Thank You

[hmmm]

I seem to get cursor corruption when "ForceLowPowerMode" is enabled on my rv635 (HD3650), print screen seems not to store/save this corruption.

I'm on a Ubuntu 9.10 install with xorg-edgers ppa and latest mainline kernel 2.6.32-rc6.

Edit: Option "ExaNoDownloadFromScreen" "TRUE" fixes it

[signor_rossi]

That was a quick response, thank you.
Seems that I have to wait again for a little (I hope it doesn't take too long ) or try to fix the X crash without KMS.

signorRossi.

EDIT: Tried again without KMS and it seems to work now (Arch has nice info on the WIKI regarding how to do it).

[agd5f]

Do power-saving options still work with KMS, DRI2 and xorg 1.7? I ask because that is the current standard configuration in Arch Linux now and with it power saving options seem not be working anymore, and without KMS X hangs. I have these messages in Xorg.log:

(WW) RADEON(0): Option "DynamicPM" is not used
(WW) RADEON(0): Option "ForceLowPowerMode" is not used
(WW) RADEON(0): Option "ClockGating" is not used

What is the status here?

There's no low power options yet with kms.

BTW, the limitation that OpenGL wouldn't output to a portion of my second monitor at all is gone! Also most other things seem to work fine, only Radeon xv is not working on the second monitor, I get a black screen there, which is no problem since I can use OpenGL or X11 outputs in mplayer.

You may need a newer radeon drm kernel modules and/or ddx depending on what versions you are currently using.

[signor_rossi]

Do power-saving options still work with KMS, DRI2 and xorg 1.7? I ask because that is the current standard configuration in Arch Linux now and with it power saving options seem not be working anymore, and without KMS X hangs. I have these messages in Xorg.log:

(WW) RADEON(0): Option "DynamicPM" is not used
(WW) RADEON(0): Option "ForceLowPowerMode" is not used
(WW) RADEON(0): Option "ClockGating" is not used

What is the status here?

BTW, the limitation that OpenGL wouldn't output to a portion of my second monitor at all is gone! Also most other things seem to work fine, only Radeon xv is not working on the second monitor, I get a black screen there, which is no problem since I can use OpenGL or X11 outputs in mplayer.

Thanks for any info, signorRossi.

[nanonyme]

Cool, but what does DRI2 have to do with power options?

Nothing at all? Mostly concentrating modesetting and memory management in kernelspace led/will lead to better (read: one that has access to both modesetting and acceleration and can do power management at the right time and in the right place without the risk of hangs or such ) power management after power management gets ported to kernel too. (and this moving/porting power management to DRM is the thing bridgman talked about)

[highlandsun]

KMS and DRI2 work fine for me with mesa 7.6 in updates-testing:

yum --enablerepo=updates-testing upgrade mesa-dri-drivers

The 3D performance regression is evident, but Compiz + DRI2 work quite fine!
This is on a Radeon 9500 AGP.

Cool, but what does DRI2 have to do with power options?

[panda84]

KMS and DRI2 work fine for me with mesa 7.6 in updates-testing:

yum --enablerepo=updates-testing upgrade mesa-dri-drivers

The 3D performance regression is evident, but Compiz + DRI2 work quite fine!
This is on a Radeon 9500 AGP.

[highlandsun]

One of the features that the Overdrive program offers on Windows is control of the memory voltage. Are the docs for programming this available so we can implement this on Linux as well? In particular, I want to try using these new 1.6V DDR2 SODIMMs in my HP dv5z notebook to try to reduce heat and power consumption.

http://www.google.com/search?hl=en&q...&aq=f&oq=&aqi=

Since I don't run Windows on this laptop, just using Overdrive isn't an option.

I've read the Family 11H BKDG but the memory controller registers described there only control the memory timing, not the voltage. This appears to be more a function of the 780 chipset, and I haven't found any docs on that yet. (And like most notebooks, the BIOS is too heavily lobotomized to provide this control there.)

edit: while we're on the subject of lobotomized notebook BIOSes, it would be nice to see CoreBoot supported on AMD Puma notebooks. It looks like right now the only issues are legal, not technical:

http://www.coreboot.org/pipermail/co...il/047490.html
http://www.coreboot.org/pipermail/co...ne/050040.html

I dunno about anyone else, but I find the closed-source stranglehold on BIOSes to be pretty aggravating. You can never get updates from your vendors on a timely basis (or at all), particularly if your board is more than several months old, and some bugs simply never get fixed. (E.g., my HP dv5z came with BIOS F.08, which had a buggy ACPI DSDT that didn't return valid results for the Thermal Zone module. As such, the Linux kernel refused to use this module, so you couldn't get temperature monitoring from ACPI. That was around 8 months ago it was released; today they're up to BIOS F.32 and it's still not fixed. I emailed various people at HP and got no response; I've been running with my own fixed DSDT since then.) With AMD's strong support of open source development, it would be a good idea to use a pure open source BIOS in all your motherboard reference designs from now on. The OEMs may not care about fixing their damn bugs, but we do.

[bridgman]

Yeah, I think this code would need to be moved into drm in order to work properly with KMS. The radeon driver in FC11 is significantly different from the one in freedesktop.org xf86-video-ati master.