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

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

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