Announcement

Collapse
No announcement yet.

X.Org ATI Driver Supports New Power Options

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Originally posted by signor_rossi View Post
    It almost seems to me that my GPU is always under load with the radeon driver, since while assumedly idling it goes up to temperatures that fglrx reached only under load. Time for a bug report maybe?
    The fglrx driver has kernel code that dynamically adjusts clock frequencies based on 2D and 3D load. The open drivers are still doing power management in the user-space driver so they can't do load-based clock switching yet. Before Alex added the recent power management options the open drivers ran the chip at full speed, while fglrx was downclocking it most of the time to save power. Using the ForceLowPowerMode option slows down the engine clock and should make the power consumption and heat generation more like fglrx.

    Once the kms/mm and 6xx/7xx 3D work in the kernel driver (drm) settles down and the APIs stabilize I imagine you'll see power management code move into the kernel and become more "dynamic". Anyways, not a bug, just lack of an architectural feature.
    Last edited by bridgman; 04-28-2009, 12:36 PM.

    Comment


    • #92
      Originally posted by bugmenot View Post
      Or apply this patch bridgman talked about and alex created. Very nice one:
      http://www.botchco.com/alex/xorg/print_clock_pm.diff
      Why not applying this patch upstream?

      Comment


      • #93
        The patch adds log entries on every clock change, so the log file would grow without limit. I don't know "how many is too many" but continuously logging events is generally frowned on unless you have a logging system which only keeps the last N entries.

        Comment


        • #94
          Originally posted by bridgman View Post
          The patch adds log entries on every clock change, so the log file would grow without limit. I don't know "how many is too many" but continuously logging events is generally frowned on unless you have a logging system which only keeps the last N entries.
          Looking at the patch it appears that it only adds the printed clock value, while before it only printed the switch, so no new entries are printed:

          current:
          Power Mode Switch

          with patch:
          Power Mode Switch: %d Mhz

          Comment


          • #95
            The info is there for debugging purposes at the moment. At some point, we'll get rid of it or make it a debug option.

            Comment


            • #96
              As long as it is for debugging purposes I think it would make sense to show the mhz. I'm also for apply this patch upstream. We linux user want to know whats going on.

              Comment


              • #97
                Just installed latest xorg git to try this out. The radeon driver hasn't crashed yet, but as a side effect I have a horribly broken evdev keyboard driver now. *sigh* :-/

                (edit: never mind - that was just my xmodmap stuff screwing things up)
                Last edited by Ant P.; 04-29-2009, 02:21 PM.

                Comment


                • #98
                  I've just tried enabling this on a Thinkpad T60p, but see the following in Xorg.0.log

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

                  I have this in the device section in xorg.conf
                  #Option "DynamicClocks" "on"
                  Option "ClockGating" "on"
                  Option "ForceLowPowerMode" "on"
                  Option "DynamicPM" "on"

                  SW levels are from Fedora 11
                  xorg-x11-drv-ati-6.12.2-15.fc11.i586
                  kernel-PAE-2.6.29.4-167.fc11.i686

                  From xorg log:
                  (II) Module radeon: vendor="X.Org Foundation"
                  compiled for 1.6.1.901, module version = 6.12.2
                  Module class: X.Org Video Driver
                  ABI class: X.Org Video Driver, version 5.0
                  (--) RADEON(0): Chipset: "ATI Mobility FireGL V5200" (ChipID = 0x71c4)

                  Why aren't these options effective, what am I missing?

                  Am I mistaken in thinking these changes made it into the fc11 rpm?

                  Is there also any way to check the current clock freq?

                  Thanks

                  Comment


                  • #99
                    @planetf1: The powermanagement-options aren't yet in a release, so you need the git-master version of xf86-video-ati. 6.12.2 is too old.

                    Comment


                    • Thanks. I've not built ati from git before, but can give it a go.

                      One thought though - with a number of dependencies between kernel/kms/libdrm/mesa, are there any particular recommendations on building a suitable git version for F11?

                      At this point I'm wondering if it just makes sense to wait until the maintainer picks this up.

                      Comment


                      • If you use fc11 that makes things pretty complicated and I'd leave my fingers from it. AFAIK fc11 already uses snapshots of a radeon git-branch (radeon-gem-cs3 I'd guess) in order to enable kms and dri2.
                        Apparently the new power options haven't made it in that branch, and quite possibly wont until the branch is merged into master again.
                        So building from git-master right now will most likely give you a not working X-Server... or if you're lucky "just" kms and dri2 will stop working.

                        Comment


                        • Originally posted by Zhick View Post
                          If you use fc11 that makes things pretty complicated and I'd leave my fingers from it.
                          Thanks for the info. That's what I guessed. Think I'll wait...

                          Comment


                          • Originally posted by planetf1 View Post
                            Thanks for the info. That's what I guessed. Think I'll wait...
                            And will also watch koji and/or f12 alpha or rawhide.

                            Comment


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

                              Comment


                              • 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.
                                Last edited by highlandsun; 06-29-2009, 01:06 AM.

                                Comment

                                Working...
                                X