Announcement

Collapse
No announcement yet.

This Is What Started AMD's Open-Source Strategy

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

  • #31
    Originally posted by Qaridarium View Post
    i think its hopeless to arguing to every one in the way that everyone can not understand why there is no working dynpm as default.
    Why is there no working dynpm by default? Because we are all waiting for you to write it.

    Dynamic power management is complicated stuff so this code has to be written by a highly skilled professional who knows what he's talking about. And since you've clearly demonstrated that you know better than everyone else (bridgman included), it's only logical that you write the dynpm code.

    You're the best man for this job Q, do not disappoint us. I'll be bugging you from time to time for status updates.

    Comment


    • #32
      Originally posted by AnonymousCoward View Post
      Why is there no working dynpm by default? Because we are all waiting for you to write it.

      Dynamic power management is complicated stuff so this code has to be written by a highly skilled professional who knows what he's talking about. And since you've clearly demonstrated that you know better than everyone else (bridgman included), it's only logical that you write the dynpm code.

      You're the best man for this job Q, do not disappoint us. I'll be bugging you from time to time for status updates.
      LOL ;-) sure but i never write programs with more than 3 lines of code (copied out of a handbook)

      but yes everyone should try his best to clear this "ugly" situation.

      Comment


      • #33
        Originally posted by smitty3268 View Post
        Q, you either believe him or you don't. If you think he's lying about the problems, then even if he gave you a link you'd just think he faked that discussion or told agd5f to make up that log. If you don't think he's lying, then why not just take him at his word and if you really want to look into the problems yourself then do the search for it rather than making it sound like you think he's lying?
        i do not write such a stuff and i don't think he is a liar.

        i just follow rules of rhetoric style.

        and i will not search in the hole universe only he claim that there is the source of his claims.

        Comment


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

          Comment


          • #35
            Is overheating a larger inconvenience than crashing or having an unreadable display ?

            If the driver defaults to "default" without power savings then the user can set a lower power mode. If the driver defaults to a power management mode which makes a system unuseable then the user's options are more limited. It's really that simple.

            When the driver reaches the point that power savings can be turned on by default without causing problems for a non-trivial number of users then I think you can safely assume that the default will be changed.
            Last edited by bridgman; 09-18-2011, 12:51 PM.

            Comment


            • #36
              If the card needs to be in "overheating mode" in order to not choke itself to death, or not randomly crash, then its useless ain't it?

              Comment


              • #37
                For the relatively small set of systems where both of the following apply ...

                (a) crash or don't display with *any* power saving mode enabled
                (b) don't have a cooling solution capable of running with default settings

                ... then the open source drivers would not be a good solution and the proprietary driver would have to be used for now. It doesn't mean the card is useless.

                The same would apply in any case where none of the power savings modes actually reduced power *and* the cooling solution wasn't capable of running at default settings... don't think I have seen any of those yet but I have seen one recently where the chip ran at a reasonable temperature but the fan noise was high enough to annoy the user.

                Note that the problem is not so much "for a single system no power savings mode works" as "there isn't a single power savings mode which works on *all* systems". The former relates to useability of a single system, while the latter relates to whether one power savings mode can be picked as default (rather than defaulting to "default" and having the user pick a mode which works for their system).

                BTW it's really important to distinguish between discussion about "should the current driver turn power savings on by default ?" with discussion about "will power management improve over time to the point where it can be turned on by default ?".

                I suspect that people are confusing the two questions, and thus misinterpreting my statement that the driver should probably not enable the current PM code by default as a statement that PM is not going to improve over time. That's only a guess, but I don't remember ever having to answer the same question so many times in a single thread before.
                Last edited by bridgman; 09-18-2011, 01:55 PM.

                Comment


                • #38
                  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

                  Comment


                  • #39
                    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?

                    Comment


                    • #40
                      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; 09-18-2011, 06:40 PM.

                      Comment


                      • #41
                        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.

                        Comment


                        • #42
                          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.

                          Comment


                          • #43
                            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, 07:37 PM.

                            Comment


                            • #44
                              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.

                              Comment


                              • #45
                                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.

                                Comment

                                Working...
                                X