This Is What Started AMD's Open-Source Strategy

[bridgman]

The power management code in the proprietary driver is huge - maybe 4x the size of the entire open source graphics stack. It's not written so that you can just take pieces out of it, unfortunately.

We realized a couple of years into the program that power management was going to be a big task, so we set an initial goal of making sure that drivers allowed users to trade off power draw vs performance, using hardware that was relatively common from one generation to the next. That's what the current PM code does, along with an initial attempt at dynamic power switching. There are a number of improvements which could be made using information that is already publicly available, but there hasn't been a lot of community interest in doing that work.

We probably need 10x the current effort to get to the next level. We have started some work internally, but it will take time.

In the meantime, previous posts suggest that Qaridarium has been tasked with improving the current power management code

[pingufunkybeat]

Fellows,

Brigdman, I understand perfectly your explanation. IMO this comes down to one of the same problems Linux faces again and again. There is no graphical interface that allows a newbie user to swap between these PM modes. If there was such a tool, i believe there wouldn't be so much fighting between the better default. Just my 2 cents.

Regards

I wrote such a GUI utility, it is quite simple. I never thought it would be interesting for others, and don't know where to put it.

The tricky part is that you need to make a C program to write to /sys/ because shell scripts do not work with setuid root on Linux. So this needs to be compiled, made to run as root, and then called from the (non-setuid root) GUI.

Otherwise it would have been a 10-liner, this way it's a bit trickier and requires installation and all those things I'm too lazy to do.

[utrrrongeeb]

The tricky part is that you need to make a C program to write to /sys/ because shell scripts do not work with setuid root on Linux. So this needs to be compiled, made to run as root, and then called from the (non-setuid root) GUI.

That shouldn't be necessary. As I just wrote here, the Debian package sysfsutils runs on boot as an init script, and can set stuff in /sys. More relevant to your software, it can set permissions on specific files -- my config for it permits the video group to set the power level.

[pingufunkybeat]

Sysfsutils is indeed available for many distros, and may be a cleaner solution, but writing from a setuid root program is simpler and works everywhere. Don't forget that it's something I hacked for myself, not a complex app.

Anyway, I'll post it since people are asking. Feel free to improve on it.

EDIT: Bah... can't attach anything here. I'll have to come back to it...

[smitty3268]

smitty3268: Overheating is the largest inconvinience a card can have. Why is that not a valid complaint?

Of course it's valid. It's just a less valid complaint than the alternative.

The options are:
default=default. Current situation. The good: All cards work, at least for a while, and you get decent performance. The bad: Some cards may overheat, it wastes power, and some cards have loud fans. The solution: write a shell script, etc, to automatically set your card to low power if that works better for you.

default=low/med. What Q and some others want. The good: You stop wasting power, get quiet cards, and no overheating. The bad: Some cards may not finish booting before they stop working, and simple apps like Compiz/Kwin might be too slow. The solution: well, there isn't one. Which is a big problem, when you can't even boot to set working settings. I guess you could add a kernel parameter, maybe.


The "Real" solution: get working dynpm. It doesn't matter what the default is then, because it will automatically select the speed your current apps need. All problems solved.

[smitty3268]

The power management code in the proprietary driver is huge - maybe 4x the size of the entire open source graphics stack. It's not written so that you can just take pieces out of it, unfortunately.

I understand you can't just copy the code out of fglrx. But shouldn't it be possible to at least take a look at the general methods being used there?

Does it store a huge table of each individual card, with it's own copies of what are acceptable parameters instead of using the VBIOS data?

Does it have absolute minimums that it never crosses even if the VBIOS says the card will, and that's why it doesn't break?

Etc. I have to think there are at least a few things you can learn from that code, even if you have to re-implement a clean version for the OSS drivers.

[Drago]

Does it store a huge table of each individual card, with it's own copies of what are acceptable parameters instead of using the VBIOS data?

Does it have absolute minimums that it never crosses even if the VBIOS says the card will, and that's why it doesn't break?

Or, AMD has more information for PM, that is not public accessible? Is there any PM logic in the GPU, which isn't documented?

[bridgman]

Just so I don't have to type it all again :

http://people.freedesktop.org/~cbrill/dri-log/index.php?channel=radeon&show_html=true&highlight_names=&date=2011-09-18

[V!NCENT]

Novell: "Yo 'sup AMD, yo dawg, G. We think we can bake them open source driver with da UVD, x264, dual display and 3D OpenGL in nine dev months from scratch 'n shit. 2D is just automatically going to work, because we have made them 3D engine work already, dawg. Let's blow this bitch!"
AMD: "OK."
V!NCENT: "What the f-...?!?!?!?!?!"


But can anyone explain to me why the power management is such a freaking pain?
You'd think it would go like this:

Driver: "'Sup GPU, what's yo number, dawg?"
GPU: "r500 homey... represent!"
Driver: "Whats da power profile, KDE?"
KDE: "High performance, g"
Driver: "Aigh-aight. What's da max temp on that one, lookup-table-g"
Loockup-table: "120 bitchin' degrees up in this mofo... Baby's sweeet!"
Driver: "Aight, so what's the temp sencor?"
Sencor: "It's coled up in here main, give me some heat bitch ass drivah dude"
Driver: "Aight... GPU, clock this up though da roof!"
GPU: "Aaaaaight... 600 extra megaHERTZ, baby! BOOM!"
Driver: "That's how we roll! What's the temp, G?"
Sencor: "It's getting hot in here, so take-"
Driver: "OK, clock down, baby"
GPU: "Word!"

No?

[Melcar]

If I am not mistaken, the hard part is having to deal with the memory.