Junior Member
Attn AMD: Fulfil your moral obligation to save the world.
AMD,
The documentation you've provided is invaluable, however there is one key area which is undocumented: power savings. I've been trolling irc looking for information on how to D3 my 4870x2 monster, and after reviewing the documents mjg59 and agd5f pointed me at, I believe we are in concordance that we need more documentation describing how to power save devices to even begin work.
This is a colossal issue. At idle, my 4870x2 still consumes ~80 watts of power. Multiply this by your impressively growing install base, and the issue becomes not just frustrating, but world threatening(sarcasm meter: high): AMD cards will soon cause ocean levels to rise and the sky to blacken. Save the world AMD, push out the docs needed to let us sleep and clock down our radeons. My system runs 24/7, yet I only ever use the video card 4-5 hours a day: during inactive times, we need a way to D3 our video card. You've a moral obligation to help your users use our hardware in an ethically responsible, non world-ending manner; please, help radeon help save the planet.
rektide
Phoronix Member
I do my part by shutting down my computer at night and putting it on suspend mode when idle for 10 minutes. Oh, I also have a highly efficient power supply. What's your usage scenario like to be running 24/7 and gaming at the same time (clearly not a mission-critical server)?
AMD Linux
It's not a documentation thing... the critical path for dynamic power management is completion of some in-process work on the driver stack.
I'm not sure what documentation you feel is needed to implement D3; how is that different from existing suspend/resume code ?
I guess our understandings may be different here; mine is that the chip does *not* turn its own power off and on, nor does the graphics driver, but perhaps I'm wrong there. AFAIK the PCI/ACPI functions to actually turn off power are vendor-specific (and vendor-proprietary) but I'll check that.
For regular dynamic power management, the fglrx driver has additional protocols to let the kernel driver combine engine and memory bandwidth requirements from display, 2D, video and 3D drawing operations, and to synchronize subsequent drawing operations with the completion of power state changes.
The corresponding architectural solution for the open drivers will be kernel modesetting, which will also allow power management code (in the kernel) to consider all requirements when choosing and implementing power states and to synchronize chip accesses with the completion of power state transitions. KMS in turn depends on memory management, and it's actually 6xx/7xx memory management support (plus stabilization of the mm code in general) that you're waiting for.
I imagine it is possible to implement a temporary dynamic power solution for the existing architecture, but it would be even more work and most of it would have to be tossed soon anyways. AFAIK the developers with the expertise in this area are waiting for KMS/GEM/TTM to stabilize first.
Are you already using the driver feature that hooks DPMS and downclocks the GPU when DPMS turns off the display ? Not sure if that code handles both GPUs today, maybe agd5f might know.
Last edited by bridgman; 05-26-2009 at 12:11 PM.
Junior Member
Hello Bridgeman, thanks for the speedy reply.
I am using this. I cant imagine how bad the situation would be without this, but I'd still like to go further.Are you already using the driver feature that hooks DPMS and downclocks the GPU when DPMS turns off the display ?
I spent a while this weekend going over documentation, but I havent dived into source yet. Its possible this may hold the keys to being able to cold state my card.I'm not sure what documentation you feel is needed to implement D3; how is that different from existing suspend/resume code ?
Honestly I'm not sure what the distinction is between this and the above. What is the distinction between the driver D3'ing the card and this vendor proprietary means of powering the card off?Or are you talking about vendor-specific (and vendor-proprietary) means to power off a card after the driver puts it in D3 cold state ? When that existins . . . I believe that is usually vendor-specific, although most vendors seem to implement ACPI methods to wrap the hardware functions.
The goal I have in mind is being able to D3 cold state the card, then to bring it up again latter when needed; my sense is that you're suggesting an ACPI d3 call will in many cases trigger some kind of vendor specific routines on the card that cause it to power done, and that all driver writers need to do is trigger that D3. What about the reciprocal case of powering the card back up; do developers know what kind of initialization needs to be done after D0'ing the card?
I guess overall I'd like clarification on what we need to know to be able to cold state a card, then bring it back up latter.
This is the one and only desktop I own, and for the most part it acts in a headless capacity doing generic dev tasks: file serving, web serving, database, and providing terminals. However it periodically does act as my gaming system, and hence has a monster video card that every now and then gets use.What's your usage scenario like to be running 24/7 and gaming at the same time
Junior Member
sic; s/Bridgeman/bridgman/Originally Posted by rektide
AMD Linux
As I understand it, the driver *prepares* the card for having power removed, while another mechanism (which I don't fully understand and obviously need to) actually removes the power. The driver is also responsible for re-initializing everything after power is restored.
As far as I know the answer is "yes", in the sense that it's really no different from initial power-up other than maybe having to manually run the ASIC init AtomBIOS command table rather than relying on the VBIOS wrapper having run it already. If that is not the case then I agree we need to get more info out there.
Here's where the wording gets tricky (and my tenuous familiarity with the area doesn't help) -- getting the chip ready for power off is clearly the graphics driver's job, while AFAIK actually yanking the power from the chip is done elsewhere.
OK, so I can see where your interest in power management comes from
Phoronix Member
bridgman, does this power saving/clock gating feature only apply to mobile cards?
Senior Member
Nope, it works even on my AGP R200.
Senior Member
Stop complaining and fix it. Just declock it a bit and devolt it a bit.
http://www.techpowerup.com/downloads...tor_v1.18.html
Start with setting stock speed down about 200mhz and dropping voltage .2 volts. Then clock it up till it artifices and write down that clock. Drop it by 20 30 mhz and set that as the default boot clock. Couple hours you'll have 80 percent of the graphics power on probably about 60 percent of the juice depending on how well your system regulates voltages.
Junior Member
Hello friend,
You seem to not be reading along, as what you suggest is only a quarter of what I've already done.
DPMS mode minimizes the various clock speeds (core and memory) and reduces the card to using a single PCIe lane.
Even still, the card is running and powered on, and in my case as well as many other's, that is not necessary.
Posting Permissions
Reply With Quote