Announcement

Collapse
No announcement yet.

For fglrx using people having idle overheating problems and eco friendly people...

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

  • #16
    Originally posted by gavro View Post
    When I try to run either one of these versions, my entire system freezes. Hard reset (poweroff) is the only way to go.

    I've got a Dell Inspiron 6400 (E1505) with an ATI X1400, running Xgl with fglrx version 8.40.4... OS: openSUSE 10.3 x86_64

    Is there any way to use this tool on my system?
    Battery drainage with the X1400 in linux is true hell..
    I hope you didn't use the provided executable because it is compiled for 32-bit and you use 64-bit.

    @OP
    thank you very very much. I compiled "your" radeontool for 64-bit Gutsy and it worked. The fan-noise was driving me crazy. And now I barely hear it, just like WinXP. I just hope that future fglrx releases fix this as soon as possible. Again thank you.

    My card: x1800xl

    Comment


    • #17
      unfortunately, i think that 64 bit is not the problem, but something else.

      I hope mr. bridgman from AMD will have some info soon about the differences between various products (x1400 vs x1950pro). the source is there, they can see what registers it touches, so it should not really be a problem..

      another option is for me to get a couple of other radeon cards but i don't have the time for that currently. maybe in the next few weeks I'll know more

      Comment


      • #18
        I tried your version of Radeontool and it complained with "Radeon control memory not found".

        But I was surprised to find a packaged version on my Ubuntu and it works... but doesn't have the "power low" option...

        So I have this..

        - Radeontool (original, unmodified)
        http://fdd.com/software/radeon/radeontool-1.5.tar.gz

        - Radeontool (adapted for Debian-based system)
        http://packages.debian.org/source/etch/radeontool

        - Radeontool (disabling unused pipes)
        http://nskunca.pbf.hr/~vedran/ati/radontool.tar.gz


        Is there a way to merge all this together?

        Even when the CPU is idle and at 28C, the GPU fans are always at max speed in Linux. It's not the case on Windows. Even more, "aticonfig --set-powerstate=1" (the only powerstate available) says that it can't process the command because thermal control is already on. So, obviously, this tweek with Radeontool would certainly help me to reduce GPU heat, hence fan speed.
        Last edited by francois; 02-21-2008, 12:59 PM.

        Comment


        • #19
          Originally posted by francois View Post
          I tried your version of Radeontool and it complained with "Radeon control memory not found".
          Hi. I've found that the debian version is patched to better detect some ATI cards. What card do you have? Can you post lspci -v and lspci -n output for your card?

          I've modified my version to include the debian changes.

          http://nskunca.pbf.hr/~vedran/ati/ra...-qq-vr2.tar.gz

          I still haven't tested it but will do so as soon as a get home later this evening.

          Comment


          • #20
            Ok here are my results with ATI Technologies X1950Pro 256MB (PCI-E)

            $ sudo ./radeontool power full (or as it was before using radeontool)

            ### After a few minutes the system is up, the GPU fan is
            ### making more and more noise due to the heat accumulating,
            ### even though the system is idle

            $ sudo ./radeontool power status
            Dynamic clock mode: single block
            Static screen enable: OFF
            Client power enable: OFF
            Lower power mode: OFF
            Static screen mode: OFF
            Disable unused clk: OFF

            $ glxgears

            21579 frames in 5.0 seconds = 4315.619 FPS
            21963 frames in 5.0 seconds = 4392.481 FPS
            28911 frames in 5.0 seconds = 5782.126 FPS
            53904 frames in 5.0 seconds = 10780.643 FPS
            53610 frames in 5.0 seconds = 10721.811 FPS
            53576 frames in 5.0 seconds = 10715.035 FPS

            ### Looks like the GPU is gradually adapting itself to the task
            ### is it? Fan is making loud noise, which is normal

            $ sudo ./radeontool power low

            ### Not even 10 seconds later the GPU fan reduced it's speed.
            ### Much better as it's now at the same level as in Windows.

            $ sudo ./radeontool power status
            Dynamic clock mode: separate blocks
            Static screen enable: OFF
            Client power enable: OFF
            Lower power mode: OFF
            Static screen mode: OFF
            Disable unused clk: ON

            ### Dynamic clock mode as changed to "separete blocks"
            ### Disable unused clk changed to "ON"

            $ glxgears
            44212 frames in 5.0 seconds = 8842.352 FPS
            53202 frames in 5.0 seconds = 10640.377 FPS
            53289 frames in 5.0 seconds = 10657.762 FPS
            53392 frames in 5.0 seconds = 10678.291 FPS
            52767 frames in 5.0 seconds = 10553.257 FPS
            52158 frames in 5.0 seconds = 10431.481 FPS

            ### Looks like the GPU is now getting faster to it's full potential... Other than that, there's nearly
            ### no performance drop. GPU fan slows down as soon as the task is ended, which is great!

            $ lspci -v (only the VGA part here)
            01:00.0 VGA compatible controller: ATI Technologies Inc RV570 [Radeon X1950 Pro] (prog-if 00 [VGA])
            Subsystem: ATI Technologies Inc Unknown device 0b12
            Flags: bus master, fast devsel, latency 0, IRQ 18
            Memory at c0000000 (64-bit, prefetchable) [size=256M]
            Memory at fbdf0000 (64-bit, non-prefetchable) [size=64K]
            I/O ports at c000 [size=256]
            Expansion ROM at fbdc0000 [disabled] [size=128K]
            Capabilities: <access denied>

            01:00.1 Display controller: ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary)
            Subsystem: ATI Technologies Inc Unknown device 0b13
            Flags: bus master, fast devsel, latency 0
            Memory at fbde0000 (64-bit, non-prefetchable) [size=64K]
            Capabilities: <access denied>

            02:00.0 VGA compatible controller: ATI Technologies Inc RV570 [Radeon X1950 Pro] (prog-if 00 [VGA])
            Subsystem: ATI Technologies Inc Unknown device 0b12
            Flags: fast devsel, IRQ 10
            Memory at d0000000 (64-bit, prefetchable) [disabled] [size=256M]
            Memory at fbef0000 (64-bit, non-prefetchable) [disabled] [size=64K]
            I/O ports at d000 [disabled] [size=256]
            Expansion ROM at fbec0000 [disabled] [size=128K]
            Capabilities: <access denied>

            02:00.1 Display controller: ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary)
            Subsystem: ATI Technologies Inc Unknown device 0b13
            Flags: bus master, fast devsel, latency 0
            Memory at fbee0000 (64-bit, non-prefetchable) [size=64K]
            Capabilities: <access denied>

            $ lspci -n (only the VGA part here)
            01:00.0 0300: 1002:7280
            01:00.1 0380: 1002:72a0
            02:00.0 0300: 1002:7280
            02:00.1 0380: 1002:72a0

            ### Conclusion:
            ###
            ### It works great !!! No loud fan noise from the GPU anymore :-)
            ###
            ### Thanx a lot !!!
            ###
            ### Note that I have 4 display ports, but only the first one is used.
            ###
            ### I don't have a double-head setup so I don't know if the second card
            ### is already turned off by xorg or if Radeontool would control the
            ### second card also.

            Edit: How come ATI hasn't integrated Radeontool's functionalities into fglrx yet?
            Once again, thank you for your mods, it's making my day!
            Last edited by francois; 02-21-2008, 05:05 PM.

            Comment


            • #21
              i looked a bit into the radeontool source and found that it is using values 0x0008 and 0x000C for CLOCK_CNTL_INDEX and CLOCK_CNTL_DATA registers instead of stated values 0xE008 and 0xE00C. strange that it works, and i don't really know why. maybe this is the source of the x1400 and x1300 problems?

              the values come from radeon_reg.h file, the one in radeontool is dated from 2002 but the one from the latest ati driver contains the same values

              bridgman?

              Comment


              • #22
                I have an X1400, and I also get a hard lockup when trying this out.

                I have discovered that removing 0x1D from clockregs[] on line 381 of radeontool.c avoids the hard lockup. After removing that and running radeontool power low, I see some significant performance reduction, so something must be working.



                I took a look at the AMD specs. I'm very new to this and I confess I'm having some trouble making heads or tails of it. For example, I looked up the questionable 0x1D clock register and it looks like it is MC_GUI_DYN_CNTRL (CLKIND:0x1D), so at least the code seems to agree with the documentation. However, I don't see some of the others mentioned at all -- the list skips from 0x1A to 0x1D with no mention of 0x1B and 0x1C. Are these just not mentioned since they are so similar to 0x1D? I feel there is something I'm supposed to take as implicit here that I don't know about.


                Originally posted by vrodic
                i looked a bit into the radeontool source and found that it is using values 0x0008 and 0x000C for CLOCK_CNTL_INDEX and CLOCK_CNTL_DATA registers instead of stated values 0xE008 and 0xE00C. strange that it works, and i don't really know why. maybe this is the source of the x1400 and x1300 problems?
                It appears radeontool.c doesn't even make use of CLOCK_CNTL_INDEX and CLOCK_CNTL_DATA as defined in radeon_reg.h. Instead, in the places where (I think) they should be used, it has 0x008 and 0x00C hardwired in. Changing those to 0xE008 and 0xE00C, respectively, causes radeontool clkind to report the contents of all the clock registers to be zero, so either I made the wrong changes, there is something wrong with the docs, or there is something else going on in the code.


                The output of the pertinent commands is here: http://pastebin.com/m234982f1

                Running 8.02 on Ubuntu gutsy.

                Comment


                • #23
                  Originally posted by larry View Post

                  I have an X1400, and I also get a hard lockup when trying this out.

                  I have discovered that removing 0x1D from clockregs[] on line 381 of radeontool.c avoids the hard lockup. After removing that and running radeontool power low, I see some significant performance reduction, so something must be working.
                  Performance reduction or temperature reduction? Or both? EDIT, Ok I see from the logs in pastebin. Strange, I guess the driver is modifying those. What's the rough idle temperature difference between Windows and Linux, if radeontool power low is not run?


                  I took a look at the AMD specs. I'm very new to this and I confess I'm having some trouble making heads or tails of it. For example, I looked up the questionable 0x1D clock register and it looks like it is MC_GUI_DYN_CNTRL (CLKIND:0x1D), so at least the code seems to agree with the documentation. However, I don't see some of the others mentioned at all -- the list skips from 0x1A to 0x1D with no mention of 0x1B and 0x1C. Are these just not mentioned since they are so similar to 0x1D? I feel there is something I'm supposed to take as implicit here that I don't know about.
                  I don't know. If it's causing X1400 to hard lock, I suppose we shouldn't touch that.


                  It appears radeontool.c doesn't even make use of CLOCK_CNTL_INDEX and CLOCK_CNTL_DATA as defined in radeon_reg.h. Instead, in the places where (I think) they should be used, it has 0x008 and 0x00C hardwired in. Changing those to 0xE008 and 0xE00C, respectively, causes radeontool clkind to report the contents of all the clock registers to be zero, so either I made the wrong changes, there is something wrong with the docs, or there is something else going on in the code.
                  It uses 0x0008 and 0x000C literaly, but the values are the same as in radeon_reg.h. Since 0xE008 and 0xE00C don't seem to work for me either, I'll assume it's some kind of an error.
                  Last edited by vrodic; 02-22-2008, 05:57 AM.

                  Comment


                  • #24
                    0xE008 and 0xE00C doesn't work because that memory is not mapped in the radeontool source code.
                    This is the line:
                    radeon_cntl_mem = map_devince_memory(base,0x2000);

                    So it only maps first 8kb
                    and 0xE008 is 57352

                    I haven't tested with the larger map yet.

                    Comment


                    • #25
                      hardlock

                      Originally posted by larry View Post
                      I have an X1400, and I also get a hard lockup when trying this out.

                      I have discovered that removing 0x1D from clockregs[] on line 381 of radeontool.c avoids the hard lockup. After removing that and running radeontool power low, I see some significant performance reduction, so something must be working.
                      I am one of these poor unfortunate X1400 users as well... in my laptop (*sigh*).

                      I can confirm that before this change I got the hard lockup, and afterwards, no lock. (I should add for posterity that I switched from the qq patch to qq-vr2 but I don't know if that matters.) However when I do radeontool power status it doens't show that I changed power modes. And I don't see any reduction in performance (it was already getting only 60fps in glxgears so it would have to try pretty hard to get much worse).

                      Everything runs very slowly while glxgears is running though, I will say that. But that was probably true before.

                      My guess is that, on the x1400 at least, radeontool does nothing (at least for now).

                      Comment


                      • #26
                        okay; mobility X1600 user here - and this is what I have found out:

                        No system lock ups or anything of that nature. However, when running with 'power low', I get around 14-15% less FPS in glxgears - and no noticable temperature difference, either in use or idle. When I switch back to 'power full', I get all of my FPS back.

                        Maybe this is something that works only with the very latest chipsets ?..

                        (side note: i get around 5000fps in normal use of glxgears with 8.02 fglrx - with compiz running. Havent tried out a 'bare' run yet .. but my numbers seem a bit low compared to other's.. Are they ?)

                        Comment


                        • #27
                          Originally posted by pedepy View Post
                          (side note: i get around 5000fps in normal use of glxgears with 8.02 fglrx - with compiz running. Havent tried out a 'bare' run yet .. but my numbers seem a bit low compared to other's.. Are they ?)
                          I wasn't kidding about that 60 FPS thing. Actually it is so consistently close to 60fps that I think it may have been throttled somehow. Why is my luck so sucky? I just double checked that libGL was the right file and it was... I'm pretty short on ideas now. I'm going to try removing openGL altogether and then reinstalling the ati drivers. But maybe it is just an x1400 thing....... oy.

                          Comment


                          • #28
                            Fan controller started with the RV630 is integrated and hopefully its AIBs will use that for future products. For earlier graphics cards, fan speed monitoring may come with trial and error since they can't release customer information (which company is using what fan controller externally). Power management is becoming a priority.
                            http://www.phoronix.com/scan.php?pag...bridgman&num=1

                            I guess it applies not only to the open-source source driver but with fgrlx also... hence the troubles with radeontool ?

                            Comment


                            • #29
                              Originally posted by benwick View Post
                              I wasn't kidding about that 60 FPS thing. Actually it is so consistently close to 60fps that I think it may have been throttled somehow. Why is my luck so sucky? I just double checked that libGL was the right file and it was... I'm pretty short on ideas now. I'm going to try removing openGL altogether and then reinstalling the ati drivers. But maybe it is just an x1400 thing....... oy.
                              You don't by any chance have sync to vblank enabled?

                              Comment


                              • #30
                                Originally posted by vrodic
                                What's the rough idle temperature difference between Windows and Linux, if radeontool power low is not run?
                                I'm not sure yet, but I will find out. I put Windows on this laptop again but I'm having trouble getting a temperature reading at all. What's the most reliable way to get a GPU temperature reading under Windows?

                                Originally posted by vrodic
                                0xE008 and 0xE00C doesn't work because that memory is not mapped in the radeontool source code.
                                Ah... figured I was missing something.

                                Originally posted by chefkoch View Post
                                You don't by any chance have sync to vblank enabled?
                                That's probably the case -- the easy way to check is to look in the AMD control center under 3D -> More settings and make sure the "vertical refresh" slider is set to "performance". I was experiencing the same behaviour until I changed this.

                                Comment

                                Working...
                                X