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

[vrodic]

While reading radeonhd dev mailing list I stumbled upon a link to a modified version of radeontool that enables setting power saving registers on new radeon adapters. I've tested it with my Radeon 1950Pro, and sure enough, the card is much cooler when idle (about the same as in Windows).

This version changes a couple of settings in the CLKIND power saving registers of which I believe that the "Auto disable unused pipes' clk" (DYN_SCLK_PWMEN_PIPE in ATI documentation) bit is the most important . When running "./radeontool power low" my glx performance falls from about 12000 FPS to 7000FPS. I've changed the modified radeontool to only enable the 'Auto disable unused pipes clk" power saving bit, and the performance of glxgears came back to 12k FPS level, while retaining a cool device.

So I've put the radeontool binary in my /usr/local/sbin, did a chown root:root radeontool, and chmod +s radeontool, and made gnome to issue "radeontool power low" command when staring up to workaround the bug in the current fglrx driver.

Radeon tool commands:
radeontool power status - show the current status of the power saving registers
radeontool power low - enable power saving


I still don't know how to read the temperature sensor data from the card and if anybody knows the relevant registers or other way to access this info, please tell. I used Windows freshly booted after linux and my own fingers to see the temperature differences.

Temperature without using radeontool: 50 C
Temperature after using radeontool: 40-41 C

Link to the radeon hd mailing list:
http://lists.opensuse.org/radeonhd

Link to the discussion:
http://lists.opensuse.org/radeonhd/2007-11/msg00069.html

Direct link to the original modified radeon tool:
http://www.g2inf.one.pl/~anszom/MBP-ATI/

My modified version that only turns on disabling of the unused pipes is here EDIT updated version:
http://nskunca.pbf.hr/~vedran/ati/radeontool-1.5-qq-vr2.tar.gz

Older version:
http://nskunca.pbf.hr/~vedran/ati/radontool.tar.gz

Relevant documentation from ATI:
http://www.x.org/docs/AMD/RRG-216M56-03oOEM.pdf

[grigi]

Well I must say that I'm impressed. On my Acer 8204Wlmi I used to only get an idle of ~21W, but using this shaved off 1-2 Watts off my power consumption. It actually idles at ~19.3W now.

The best thing is I can't even measure a performance difference. I'm using fglrx with all the normal power-savings enabled, and even using the full "low" power options I cannot measure a performance difference. Maybe it is because powerplay is already active in fglrx?

[domi]

My modified version that only turns on disabling of the unused pipes is here:
http://nskunca.pbf.hr/~vedran/ati/radontool.tar.gz


Great work. Are radeontool maintainers aware of it ?

[gavro]

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

[vrodic]

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'm not sure how exactly is this chip is special... Maybe there's something in the released specs about that, but I don't have the hardware...

[bridgman]

Apparently a couple of registers are in a different location on the RV515 (X1400) than they are on the rest of the 5xx family. The ones we have found so far are :

MC_FB_LOCATION -- 0x04 indirect for all but 515, 0x01 for 515
MC_AGP_LOCATION -- 0x05 indirect for all but 515, 0x01 for 515

I suspect that other adjacent registers also moved -- checking now. Also trying to figure out exactly which chips have the different register offsets.

[gavro]

The X1400 is a strange duckling if you ask me... I always see X1300, X1600 and so on, but never any details about X1400 (or to put it differently: strange reports concerning the X1400). And now those registers... What have they done with the X1400? Why is this one 'weird'/different than the other 5xx cards?

[grigi]

Just a note of interest, on my Mobility X1600 256MB I notice that "Static screen enable" and "Static screen mode" both seem to return OFF when notebook is only running off the LVDS, and ON when I have an external monitor also connected.

Just reporting that I think those 2 registers are used wrongly.

Also, writing to those registers, the values get ignored. (Possibly read-only on my card)

Edit: I think that this should be well-investigated and added to fglrx as an optional power-saving mode controlled by atieventsd (or something) because it made a considerable difference in thermals on my notebook. Now when idling for a while, the hard-drive is clearly the warmest device in my notebook, the exhaust is roughly skin temperature. Much more comfortable to use on your lap than before.

[vrodic]

Apparently a couple of registers are in a different location on the RV515 (X1400) than they are on the rest of the 5xx family. The ones we have found so far are :

MC_FB_LOCATION -- 0x04 indirect for all but 515, 0x01 for 515
MC_AGP_LOCATION -- 0x05 indirect for all but 515, 0x01 for 515

I suspect that other adjacent registers also moved -- checking now. Also trying to figure out exactly which chips have the different register offsets.

Thanks John. I'll try to do a fix later, also please do that checking for the other chips.

Regarding the maintaining of the radeontool, I don't think that it's actively maintained, but I'll let the authors know about my changes.

[Porter]

Bridgman,

Is it possible to enable this behavior by default in the next revision of fglrx?

[bridgman]

Realistically, I don't think so -- but for the short term I can at least find out if that register is known to have bad side effects and make sure we answer any questions the radeontool devs might have.

[Porter]

The reason I asked is because the Windows driver seems to do this by default. Is the ultimate goal to replicate the behavior of the Windows driver packages, under Linux?

Thanks for your insight... it helps us understand where the project is going.

[bridgman]

Short answer is yes. There will be some features which we can't offer directly on Linux (anything starting with DX, for example ;)), but in general we are working towards having the same or comparable functionality across all OSes.

[gavro]

Any updates on the registers? I would like to use readontool, as I cannot use aticonfig powerstate options (openSUSE 10.3, Driver 8.40, Xgl, cannot pass anything to the Xserver...).

[mits]

no luck it seems with my 2600 mobility :(
i guess the patch is for cards up to the r500 series?
aticonfig --set-powerstate doesn't work either... :( (says powerplay not supported by the hardware...is anything else needed for that one to work?)

[SledgeHammer_999]

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

[vrodic]

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

[francois]

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.

[vrodic]

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/radeontool-1.5-qq-vr2.tar.gz

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

[francois]

Ok here are my results with ATI Technologies X1950Pro 256MB (PCI-E) :D

$ 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? :confused:
Once again, thank you for your mods, it's making my day!

[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?

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?

[larry]

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.


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.

[vrodic]

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.

[vrodic]

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.

[benwick]

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

[pedepy]

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 ?)

[benwick]

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

[francois]

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?page=article&item=fosdem_08_bridgman&num=1

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

[chefkoch]

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?

[larry]

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?

0xE008 and 0xE00C doesn't work because that memory is not mapped in the radeontool source code.

Ah... figured I was missing something.

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.

[benwick]

I'll be damned, I forgot all about amdcccle (I'd set the "refresh" option to fix the flicker, and it didn't do it, but I figured it eventually would.) Ok, now I can get 3300 fps on glxgears for whatever good that does...

...Since I really only care about video I'm still screwed. Thanks for the tip though! I feel like we're on the verge of a breakthrough.

(Off the record I also felt that way in January... December... November...)

[larry]

Ok, now I can get 3300 fps on glxgears for whatever good that does...

Is there any FPS difference after using radeontool power low?

[benwick]

Is there any FPS difference after using radeontool power low?

I'll be damned. It actually did do something... I lost 500fps. To wit:

fozzie ~ # glxgears
16998 frames in 5.0 seconds = 3399.512 FPS
17024 frames in 5.0 seconds = 3404.605 FPS
17029 frames in 5.0 seconds = 3405.675 FPS
17019 frames in 5.0 seconds = 3403.646 FPS
16997 frames in 5.0 seconds = 3399.334 FPS
17020 frames in 5.0 seconds = 3403.837 FPS
17023 frames in 5.0 seconds = 3404.507 FPS
^C
fozzie ~ # radeontool power low
fozzie ~ # glxgears
13017 frames in 5.0 seconds = 2603.305 FPS
14592 frames in 5.0 seconds = 2918.337 FPS
14595 frames in 5.0 seconds = 2918.807 FPS
14593 frames in 5.0 seconds = 2918.411 FPS
14596 frames in 5.0 seconds = 2919.118 FPS
14594 frames in 5.0 seconds = 2918.684 FPS

Anybody have a good way to measure power consumption (aside from just running X, unplugging the computer and seeing how long it lasts before auto-shutdown?) :)

[vrodic]

Anybody have a good way to measure power consumption (aside from just running X, unplugging the computer and seeing how long it lasts before auto-shutdown?) :)

There is a handy device, I think it is called kill-a-watt in US, and there are different versions for European and other markets..

[vrodic]

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?

.

ATI control center or whatever's the name of the application. There is temperature monitoring somewhere, at least for my X1950Pro.

[piete]

Hi! Any progress on this? I just got myself a used HP NC8430 notebook with Mobility X1600 (my first laptop with a "proper" GPU) and it is heating a bit outside windows or linux's fglrx (=text console mode, installations, live environments etc.)

I tried both radeontool (with modifications, I even added some of my own with the help of ATI's pdf document) and rovclock, but I haven't reached CCC/fglrx power state 1 temperatures. I don't know much about programming (just enough to modify somebody other's code) but I was thinking that if you could dump all the registers in two (or more) different power states and compare the changes, wouldn't you be able to "reverse engineer" the same for these tools? I think there is more than just changing some registers, with Glisse's atomtools I could set the core/mem clocks to the power state 1 equivalent frequencies, but the cooling was not sufficient so there must be more to it.

[tball]

Nevermind. :-)