Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 58

Thread: This Is What Started AMD's Open-Source Strategy

  1. #41
    Join Date
    Jun 2009
    Posts
    2,932

    Default

    Quote Originally Posted by Figueiredo View Post
    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.

  2. #42
    Join Date
    Feb 2011
    Posts
    26

    Default

    Quote Originally Posted by pingufunkybeat
    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.

  3. #43
    Join Date
    Jun 2009
    Posts
    2,932

    Default

    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.

  4. #44
    Join Date
    Oct 2008
    Posts
    3,173

    Default

    Quote Originally Posted by del_diablo View Post
    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.

  5. #45
    Join Date
    Oct 2008
    Posts
    3,173

    Default

    Quote Originally Posted by bridgman View Post
    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.

  6. #46
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    526

    Default

    Quote Originally Posted by smitty3268 View Post
    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?

  7. #47
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

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

    http://people.freedesktop.org/~cbril...ate=2011-09-18

  8. #48
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    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?

  9. #49
    Join Date
    Dec 2007
    Location
    Merida
    Posts
    1,104

    Default

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

  10. #50
    Join Date
    Sep 2011
    Posts
    3

    Default

    Quote Originally Posted by V!NCENT View Post
    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!"
    Flexible clockspeed = killer driver feature. Nice GUI for config & monitoring makes it a winner.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •