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.
Originally Posted by Figueiredo
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.
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.
Originally Posted by 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...
Last edited by pingufunkybeat; 09-18-2011 at 07:37 PM.
Of course it's valid. It's just a less valid complaint than the alternative.
Originally Posted by del_diablo
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.
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?
Originally Posted by bridgman
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.
Or, AMD has more information for PM, that is not public accessible? Is there any PM logic in the GPU, which isn't documented?
Originally Posted by smitty3268
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!"
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"
If I am not mistaken, the hard part is having to deal with the memory.
Flexible clockspeed = killer driver feature. Nice GUI for config & monitoring makes it a winner.
Originally Posted by V!NCENT