2009/5/29 Alex Deucher <alexdeucher@gmail.com>:
On Fri, May 29, 2009 at 1:57 AM, David C. Rankin, J.D.,P.E. <drankinatty@suddenlinkmail.com> wrote:
On or about Friday 29 May 2009 at approximately 00:41:01 David C. Rankin, J.D.,P.E. composed:
On or about Friday 29 May 2009 at approximately 00:01:26 Rafał Miłecki
composed:
2009/5/29 David C. Rankin, J.D.,P.E. <drankinatty@suddenlinkmail.com>:
Rafał,
That's what I needed to know. I'm am not familiar with 'git' and the
git checkout -t -b downclocking origin/master git am ~/archlinux/radeonhd/patches/*patch
parts were the parts I knew nothing about. I'll pull the patches, apply and report back. Something really has to give here. The heat is unbearable. To get the actual temp data, I have a digital multimeter with a great surface temperature probe on it ( Craftsman Model No. 82400 ) and I took the temperature readings on the left palm rest and left fan discharge of my laptop with the radeonhd driver active. The results:
Left Palm Rest Temp: 96 Deg. F
Left Fan Discharge: 147 Deg. F
The inside of this box is cooking.... That's with:
Option "ForceLowPowerMode" Option "LowPowerModeEngineClock" "140000"
I'll keep my fingers crossed and report back.
Nice, tests with your multimeter would be absolutely great. You may also try to reduce EngineClock later. For example change it from 140000 to 120000. If it doesn't cause any corruptions you can still try decreasing that. Don't worry about values you may use 139999, 139998, 139997, end so on.AtomBIOS will round it to something acceptable.
-- Rafał Miłecki
Uh oh,
I have some good news and I have some bad news. I did some additional testing with compiz and on cube rotate, I can't view the cube-caps any longer (the cube keeps jumping around) and when trying to rotate the cube, it will not rotate all the way around. It gets roughly 1/2 - 3/4 way around and then stops and you are left on desktop 3 or 4. Strange, I haven't seen that with the radeonhd driver before.
For testing purposes, I backed out the downclocking by setting:
#if 0
in src/rhd_pm.c and compiz returned to normal. I don't know why it makes a difference, but it makes a real difference to the cube rotate function. Just one more challenge for the driver team ;-)
This is the tricky part of power management. You need to slow the clock at the right times otherwise you can negatively impact the user experience. If you are going to run with reduced clocks you need to take into account the bandwidth requirements (display controllers, 2D engine, 3D engine, overlays, etc.) and latency requirements (frame has to be rendered in this amount of time). That's why the best place for power management will be in the new kms drm since only there does the driver have the full view of the hw (modesetting and command streams) so that it can change the clocks on demand in response to the current demands of the chip.
Alex
To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
I found the best way of determining the effectiveness of any power saving technique is to test it on a laptop running on a battery and look at the difference in the discharge rate of the battery with the following command. cat /proc/acpi/battery/BAT1/state I determined with the power management that is in the master branch now it saved 100mA of current or about 1.2 watts. I would expect with the memory downclocking it will be much more. -- Conn Conn O. Clark Observation: In formal computer science advances are made by standing on the shoulders of giants. Linux has proved that if there are enough of you, you can advance just as far by stepping on each others toes. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org