Announcement

Collapse
No announcement yet.

This Is What Started AMD's Open-Source Strategy

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    Leave a comment:


  • Drago
    replied
    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?

    Leave a comment:


  • smitty3268
    replied
    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.

    Leave a comment:


  • smitty3268
    replied
    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.

    Leave a comment:


  • pingufunkybeat
    replied
    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; 18 September 2011, 07:37 PM.

    Leave a comment:


  • utrrrongeeb
    replied
    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.

    Leave a comment:


  • pingufunkybeat
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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
    Last edited by bridgman; 18 September 2011, 06:40 PM.

    Leave a comment:


  • RussianNeuroMancer
    replied
    Brigdman, but how all such problems solved in properietary driver? Isn't you can just look at already existing solution and then use it in open source driver?

    Leave a comment:


  • Figueiredo
    replied
    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

    Leave a comment:

Working...
X