Posted Feb 12, 2009 16:10 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
a couple of reasons.
1. even when the GPU has finished doing it's work you still want to see the screen (which requires that the GPU stay on)
2. changing the GPU mode can cause artifacts on the screen (mentioned in the article when talking about changing the clock speed)
3. switching modes takes time, you frequently don't want to drop too far as you then won't be able to respond to activity quickly. If you only switch modes when the entire system is idle, then you miss a lot of chances to save power.
FOSDEM09: "Aggressive" Linux power management
Posted Feb 12, 2009 16:24 UTC (Thu) by johnkarp (subscriber, #39285)
[Link]
Re #1, isn't video memory typically dual-ported, so that the RAMDAC can still read the memory even while the GPU is inactive?
FOSDEM09: "Aggressive" Linux power management
Posted Feb 12, 2009 16:41 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
this will vary from video system to video system. some cards did use dual-port ram, but since some 'cards' can use your system ram, there are definantly 'cards' where that is not the case.
I don't know what's common on modern high-end cards
FOSDEM09: "Aggressive" Linux power management
Posted Feb 13, 2009 8:30 UTC (Fri) by Los__D (guest, #15263)
[Link]
I thought that cards using system RAM only used it for texture caches, and so on?
FOSDEM09: "Aggressive" Linux power management
Posted Feb 19, 2009 22:26 UTC (Thu) by wmf (guest, #33791)
[Link]
I think dual-ported VRAM was eliminated 5-10 years ago, and the RAMDAC has been part of the GPU for 10-15 years. It is probably possible to gate the command processor and shader pipelines while leaving the refresh logic on, though.
FOSDEM09: "Aggressive" Linux power management
Posted Feb 12, 2009 17:25 UTC (Thu) by iabervon (subscriber, #722)
[Link]
With most programs, there's some task that the program gets done (processes a packet, adds a letter to a document, compiles a file, etc.), and, in order to be working correctly, it has to do this work eventually. With graphics, in general, the program is producing images to be displayed in real time, and if it's late fewer frames are produced and the program actually does less work.
Furthermore, they sometimes run without a maximum amount of work; whenever they finish a frame, they start the next one.
Race-to-idle doesn't work at all if there is no idle state, and doesn't necessarily work the same way if being late means doing less work (possibly with a loss of output quality).
race-to-idle
Posted Feb 12, 2009 17:59 UTC (Thu) by anton (guest, #25547)
[Link]
Why doesn't the 'race-to-idle' concept apply to GPUs?
It does not apply in general to CPUs, either. E.g., my current
desktop draws 100W idle, 111W at load 1 2GHz, and 123W at load 1 3GHz.
If I have a job that consumes 6G cycles every 3s, then at race-to-idle
3GHz it will consume (123*2+100)/3=115W, whereas at 2GHz it will
consume 111W.
Race-to-idle may work on systems that really power down at idle,
but for most of the systems
I have measured this does not happen to a significant extent, and
the effects of voltage scaling dominate, making it beneficial to run
at the lowest clock and voltage that is sufficient for the load.
race-to-idle
Posted Feb 13, 2009 23:11 UTC (Fri) by giraffedata (subscriber, #1954)
[Link]
In CPUs, I think race-to-idle is valid only for lower speeds, such as were common five years ago. Above 1.5 GHz or so, the curve starts bending down and it takes more power to squeeze out each additional MHz (which is why we finally hit a wall and can't make them go faster).
I've noticed the same thing with CPU price. That third GHz costs you more than the second.
race-to-idle
Posted Feb 14, 2009 4:12 UTC (Sat) by i3839 (guest, #31386)
[Link]
It's not related to slow speed. That curve is probably always there, for that generation of processors. Modern processors clocked slower is a different matter, those are basically already underclocked.
I think the whole race-to-idle thing is overrated. It might be true if you look at servers or something, or when you are waiting for something to finish before doing anything else, but in general it seems just running at lower cpu speed (and voltage) uses less power. Especially with laptops it's not just the cpu, the screen and other things take a lot of energy as well, and those are on no matter what.
For my Thinkpad X40 with 1.4GHz Pentium M the numbers are (CPU undervoltaged with PHC patch, otherwise plain kernel), more or less, network cable plugged and LCD at usable brightness:
10W idle, 16W max cpu speed (20W without undervoltage), and 12W for fixed 600MHz 100% cpu usage.
4W more power draw for 2.3 "speedup" seems like a good deal, until you realize that what you're doing isn't cpu limited and that you use the thing for something all the time anyway (I call it "reading"/"staring").
So for one hour of 100% cpu usage at 600MHz the total power usage is:
1h * 12W = 12Wh.
For the same task done with race to idle it is:
t = 1/2.3h
t * 16W + (1 - t) * 10W = 12.6Wh
Which at best proves that it doesn't matter much. Without undervoltage the numbers aren't as good though:
1h * 13W = 13Wh
and
t * 20W + (1 - t) * 10W = 14.3Wh
which results in 10% less battery life, or about half an hour.
Throw in the more heat and fan noise, and I'm happy if it stays at 600MHz for cpu intesive tasks taking a while. That said, the default cpufreq does the right thing and puts the cpu at 600MHz speed almost all the time anyway.
Of course that it all doesn't matter all that much may prove that the race-to-idle exists, so you can interpret the results to your liking. But claiming that doing it one way is substantially better than doing it another way seems far fetched. Perhaps the thruth is somewhere in the middle, with best results with cpufreq with a max speed of 1GHz for this setup.
FWIW, the minimum idle power usage is about 6W for this laptop, with everything more or less off or idle/unplugged. That seems way too much for doing nothing (suspend to ram is about 1W, in a perfect world total idle should be about the same, with suspend case using even less energy of course). Oh well.