Any schedule yet to advance downclocking ability?
Listmates, I was just curious if the downclocking/chip powerdown issue was scheduled for more work anytime soon. The reason I ask is that I have the perfect laptop to test any patches, etc. on. This Toshiba 205D is so hot I keep having to lift my left hand up off the palm rest with the current driver without downclocking by at least 75% of the clock. With the fglrx driver, it is cool 90% of the time (It will still get hot with the fglrx driver if I'm doing full-screen video/screensavers, etc., but other than that it is cool) If/when more work is done on this issue, I'll make this frying pan available for testing because it would really help if we could find a way to improve the powerdown capabilities of the driver. Lastly, is there any way to manually send a command to the driver while in use that will do the same thing as ForceLowPowerMode and LowPowerModeEngineClock do from within xorg.conf. It would be great to be able to set the LowPowerModeEngineClock from the command line to drop the temps when I don't need the gpu clock running at 100% and then be able to bring it back to 100% when I do. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/5/22 David C. Rankin, J.D.,P.E.
Lastly, is there any way to manually send a command to the driver while in use that will do the same thing as ForceLowPowerMode and LowPowerModeEngineClock do from within xorg.conf. It would be great to be able to set the LowPowerModeEngineClock from the command line to drop the temps when I don't need the gpu clock running at 100% and then be able to bring it back to 100% when I do. Thanks.
I have some code that exposes engine and memory clock as output properties in xrandr: both reading and setting works. The bigger issue is that the wait-for-idle code needs to be refactored so that it can be more easily called by subcomponents; the AtomBIOS calls do nothing unless the GPU is sufficiently idle for clock changing. It's on my TODO, but I've been kept busy. Soon, hopefully. And don't let that stop someone else from attempting the same. ;) Cheers, -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/5/22 Yang Zhao
The bigger issue is that the wait-for-idle code needs to be refactored so that it can be more easily called by subcomponents; the AtomBIOS calls do nothing unless the GPU is sufficiently idle for clock changing.
Interesting. Can you explain me something? Let's say my memory default clock is 800'000. I call RHDSetMemoryClock(400000); and then RHDGetMemoryClock(); which returns 400000. Is this possible that my memory clock is still at 800000 if setting was called in wrong moment? -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/5/22 Rafał Miłecki
2009/5/22 Yang Zhao
: The bigger issue is that the wait-for-idle code needs to be refactored so that it can be more easily called by subcomponents; the AtomBIOS calls do nothing unless the GPU is sufficiently idle for clock changing.
Interesting. Can you explain me something? Let's say my memory default clock is 800'000. I call RHDSetMemoryClock(400000); and then RHDGetMemoryClock(); which returns 400000.
Is this possible that my memory clock is still at 800000 if setting was called in wrong moment?
AFAIK, no. The GetMemoryClock AtomBIOS call calculates the effective clock using values read from the various related registers. The returned value does not change unless the register value themselves were changed. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On May 22, 09 10:16:46 +0200, Rafał Miłecki wrote:
Interesting. Can you explain me something? Let's say my memory default clock is 800'000. I call RHDSetMemoryClock(400000); and then RHDGetMemoryClock(); which returns 400000.
Is this possible that my memory clock is still at 800000 if setting was called in wrong moment?
No, but chances are that the SetMemoryClock() could crash the system
when called when the chip is not idle.
Matthias
--
Matthias Hopf
On Wednesday 03 June 2009 11:30:12 am Matthias Hopf wrote:
On May 22, 09 10:16:46 +0200, Rafał Miłecki wrote:
Interesting. Can you explain me something? Let's say my memory default clock is 800'000. I call RHDSetMemoryClock(400000); and then RHDGetMemoryClock(); which returns 400000.
Is this possible that my memory clock is still at 800000 if setting was called in wrong moment?
No, but chances are that the SetMemoryClock() could crash the system when called when the chip is not idle.
Matthias
You guys just let me know when you have anything you need tested concerning downclocking, and I'm happy to do it. My kde4.3 2.92 on Archlinux looks much better than 2.90 on suse, but the heat issue still prevents me from using the arch install for more than testing really. So just let me know when I need to pull from the repository (and any special instruction to get the pieces I need) and I'll test away. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
W dniu 3 czerwca 2009 18:30 użytkownik Matthias Hopf
On May 22, 09 10:16:46 +0200, Rafał Miłecki wrote:
Interesting. Can you explain me something? Let's say my memory default clock is 800'000. I call RHDSetMemoryClock(400000); and then RHDGetMemoryClock(); which returns 400000.
Is this possible that my memory clock is still at 800000 if setting was called in wrong moment?
No, but chances are that the SetMemoryClock() could crash the system when called when the chip is not idle.
For very fast test I pushed following code: RHDGetMemoryClock(rhdPtr); RHDSetMemoryClock(rhdPtr, 400000 + (level * 1000)); RHDGetMemoryClock(rhdPtr); at end of static void DigLVDSSetBacklight(...) function. I can change memory clock without any problems and it seems to really work: (II) RADEONHD(0): Current Memory Clock: 495000 (II) RADEONHD(0): Attempting to set Memory Clock to 600000 (II) RADEONHD(0): Current Memory Clock: 594000 (II) RADEONHD(0): Current Memory Clock: 594000 (II) RADEONHD(0): Attempting to set Memory Clock to 540000 (II) RADEONHD(0): Current Memory Clock: 540000 (II) RADEONHD(0): Current Memory Clock: 540000 (II) RADEONHD(0): Attempting to set Memory Clock to 560000 (II) RADEONHD(0): Current Memory Clock: 558000 (II) RADEONHD(0): Current Memory Clock: 558000 (II) RADEONHD(0): Attempting to set Memory Clock to 580000 (II) RADEONHD(0): Current Memory Clock: 576000 Don't know if it is just my AtomBIOS that idles everything needed itself, or what, but it works. Tested even with Xv playing. Is this possible that some other AtomBIOSes don't idle needed blocks and this will hang X/GPU? -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On May 22, 09 01:04:36 -0700, Yang Zhao wrote:
2009/5/22 David C. Rankin, J.D.,P.E.
: Lastly, is there any way to manually send a command to the driver while in use that will do the same thing as ForceLowPowerMode and LowPowerModeEngineClock do from within xorg.conf. It would be great to be able to set the LowPowerModeEngineClock from the command line to drop the temps when I don't need the gpu clock running at 100% and then be able to bring it back to 100% when I do. Thanks.
I have some code that exposes engine and memory clock as output properties in xrandr: both reading and setting works. The bigger issue is that the wait-for-idle code needs to be refactored so that it can be more easily called by subcomponents; the AtomBIOS calls do nothing unless the GPU is sufficiently idle for clock changing.
Another issue is that for maximum trivial savings we need to reduce the
core voltage. Lower voltage is only allowed with lower frequencies, and
we cannot parse the current version of the according atomBIOS tables
that provide this information (and even the earlier ones are...
difficult).
Matthias
--
Matthias Hopf
participants (5)
-
David C. Rankin
-
David C. Rankin, J.D.,P.E.
-
Matthias Hopf
-
Rafał Miłecki
-
Yang Zhao