Announcement

Collapse
No announcement yet.

The State Of Open-Source Radeon Driver Features

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

  • Originally posted by liam View Post
    when Matthew chimed in, and Dave then explained why they choose not to purse static PM further (the hope seemed to be that if they didn't improve the PM further there might be more push from the AMD side to get the relevant docs for talking to the PM system
    That's a reasonable hope, but having unhappy users doesn't actually make it easier to release even more programming information. If anything it's more likely to make decision-makers question whether the whole open source driver effort is worth doing, at least that has been our experience so far.

    It is probably the case that if a *totally* satisfying PM solution could be created with the available info then that might weaken the argument for releasing more info since there would be no apparent customer benefit, but I don't think anyone was expecting the short term work to go that far.

    Originally posted by liam View Post
    and they also seemed like they wanted to avoid further code review on any changes they make) the conversation kinda stopped.
    Yep, nobody likes writing dead-end code even if it does make a big difference to user satisfaction in the short term.
    Test signature

    Comment


    • Originally posted by bridgman View Post
      That's a reasonable hope, but having unhappy users doesn't actually make it easier to release even more programming information. If anything it's more likely to make decision-makers question whether the whole open source driver effort is worth doing, at least that has been our experience so far.
      Since their strategy of having unhappy corporate users seems a bit silly, plus your comment about the possibility of AMD pulling out of the community effort altogether must have occurred to them, I have to think that they are coming from a position of privileged info. OTOH, perhaps it's as simple as hoping that by telling their clients that the problem is on your end their clients would then complain to AMD and hopefully pressure the release of the relevant docs. The other possibility seems to be that Dave doesn't have the time or the motivation in the form of requests from RH clients for this work.

      Originally posted by bridgman View Post
      Yep, nobody likes writing dead-end code even if it does make a big difference to user satisfaction in the short term.
      As you say, nobody likes writing stopgap code especially when even its utility is in question by some parties. There's also the seeming differing requests from customers that you and Dave are seeing.


      Best/Liam

      Comment


      • Originally posted by bridgman View Post
        That's a reasonable hope, but having unhappy users doesn't actually make it easier to release even more programming information. If anything it's more likely to make decision-makers question whether the whole open source driver effort is worth doing, at least that has been our experience so far.

        It is probably the case that if a *totally* satisfying PM solution could be created with the available info then that might weaken the argument for releasing more info since there would be no apparent customer benefit, but I don't think anyone was expecting the short term work to go that far.



        Yep, nobody likes writing dead-end code even if it does make a big difference to user satisfaction in the short term.
        That just doesnt make any sense though... On one hand you have a stable useable driver that is incomplete and on the other you've got a completely worthless driver that crashes just about every computer it runs on. Why would AMD stop contributing to the only good driver that supports its hardware? After all it IS their hardware. The expectation that folks who don't have the knowledge, skillset, documentation, or funding to develop a driver should have to do it by themselves for hardware that AMD should be supporting is kind of assinine. And at the very minimum it is unrealistic.

        You take away the driver and you take away the ability to use the hardware... Its simple logic if you can't use the hardware then there isnt any point in buying the hardware. Thats really stupid. With steam coming to linux right now is a really retarded time to make that choice.

        EDIT: If what you say is true about AMD's attitude internally then they have some serious problems to consider. FGLRX is ---NOT--- an adequate driver. the OSS drivers are the only workable solution for the vast majority of linux users. You take that away and AMD becomes irrelevant on linux.

        Up until this conversation I had been very optimistic about the furure of AMD products on linux, but you make it sound as if the end is very near.
        Last edited by duby229; 18 January 2013, 01:52 AM.

        Comment


        • Originally posted by duby229 View Post
          Up until this conversation I had been very optimistic about the furure of AMD products on linux, but you make it sound as if the end is very near.
          Don't let your increasing awareness of an imperfect but improving situation make you think that things are getting worse.

          I'm not going to respond to the rest of your points in detail because you're basically saying "I don't like fglrx therefore everyone so must obviously believe it's crap and if AMD funds work on it then they must be stupid" over and over again. I continue to hear that fglrx works pretty well in the applications where its primary focus lies -- 3D workstation apps -- and it seems statistically unlikely that all of those people are stupid.

          Also note that even if the open source drivers are superior for "the vast majority of Linux users" that doesn't mean fglrx doesn't have a place. Remember that fglrx's primary target is still the 3D workstation market (which is small but important), while the open source drivers *do* directly target the larger consumer and desktop client userbase.

          I guess it would be unreasonable for me to ask you and BO$$ to come up with a consensus view before we go any further ?
          Last edited by bridgman; 18 January 2013, 02:41 AM.
          Test signature

          Comment


          • I didnt say that AMD customers were stupid. I said it would be stupid for AMD to drop out of OSS driver development right now. It sounds like what you were saying is thats where things are headed. That AMD will drop out of OSS driver development.

            If I interpreted you wrong please set me straight and tell me that AMD isnt going to.

            EDIT: If you guys want to develop fglrx then thats fine... I just don't like how you use the fact that fglrx exists as an excuse for why its taking so long to bring up support for features in the oss drivers. Whenever video decode (or any other feature the oss drivers don't have) is mentioned it always come to "well fglrx exists use that, it was designed for cases that the oss drivers dont work in"... Thats all fine and good except that it doesnt work.... And then to make things worse you say that it should be up to "thousands" of community developers to do it for free with no documentation.
            Last edited by duby229; 18 January 2013, 03:36 AM.

            Comment


            • Originally posted by liam View Post
              As you say, nobody likes writing stopgap code especially when even its utility is in question by some parties. There's also the seeming differing requests from customers that you and Dave are seeing.
              That's the real disconnect I'm seeing.

              Bridgman thinks these small improvements to the static profiles would make a big difference. The oss devs think no one except a couple phoronix readers would even notice.

              I have to say, I kind of agree with Dave and the others. Improving the static profiles might help quiet a couple trolls, but 99.999999% of people need good dynamic PM, and nothing less than that matters at all. Better to spend dev time working on things people will actually care about.

              Comment


              • Please tell us Bridgman, what are these 3D workstation customer demands, that Radeon driver can't satisfy, besides superior performance. Is it GL 4.x? Is it OpenCL? Is it some secret sauce that is used to differentiate Radeon chips from FireGL ones.
                Isn't possible for FOSS driver one day in the future to be 3D Workstation compatible?
                Tell us, what you think it could be done with currently available information for PM. You said something of AtomBios table interpolation. Explain. This are super honest questions. I am not trying to argue with you, by no means.
                Thanks.
                Last edited by Drago; 18 January 2013, 06:24 AM. Reason: fix typo

                Comment


                • Can you please stop disagreeing with things I didn't say ?

                  Originally posted by duby229 View Post
                  I didnt say that AMD customers were stupid. I said it would be stupid for AMD to drop out of OSS driver development right now. It sounds like what you were saying is thats where things are headed. That AMD will drop out of OSS driver development.
                  No, I never said anything of the sort. What I said is that when we tried to use current unhappiness of users as justification to help secure the release of new programming information it doesn't work very well and tended to raise questions about whether the open source project was worth the risk. I didn't actually say "so we don't do it any more" but I guess I thought that would be obvious.

                  Originally posted by duby229 View Post
                  EDIT: If you guys want to develop fglrx then thats fine... I just don't like how you use the fact that fglrx exists as an excuse for why its taking so long to bring up support for features in the oss drivers.
                  Don't think I have ever said anything like that. Citation needed.

                  Originally posted by duby229 View Post
                  Whenever video decode (or any other feature the oss drivers don't have) is mentioned it always come to "well fglrx exists use that, it was designed for cases that the oss drivers dont work in"... Thats all fine and good except that it doesnt work.... And then to make things worse you say that it should be up to "thousands" of community developers to do it for free with no documentation.
                  Again, you're re-arranging my words to give them different meaning. Only Q is allowed to do that

                  I have said that we targetted the open source drivers at areas where fglrx was weak, but not the other way round. I never said that it should be up to "thousands of developers" other than summarizing what others were saying around the start of the project 5 years ago. My expectations were basically what we worked out with Dave and Alex in mid-2007 and so far things have worked out as planned, maybe a bit better if anything.
                  Last edited by bridgman; 18 January 2013, 10:47 AM.
                  Test signature

                  Comment


                  • Originally posted by Drago View Post
                    Please tell us Bridgman, what are these 3D workstation customer demands, that Radeon driver can't satisfy, besides superior performance. Is it GL 4.x? Is it OpenCL? Is it some secret sauce that is used to differentiate Radeon chips from FireGL ones.
                    Mostly superior performance, particularly on specific workloads AFAIK. The requirement used to be maximum performance on vertex-intensive workloads eg wireframe models while consumer apps cared more about pixel shading performance. GL levels are more of a "checkbox" requirement, ie if you don't have them then your cards don't get bought even if current apps mostly use GL 2.1 and lower.

                    There are some other requirements like GL overlays (for floating a UI over a full screen model) but I think it's the first two that require a big development effort.

                    Originally posted by Drago View Post
                    Isn't possible for FOSS driver one day in the future to be 3D Workstation compatible?
                    Sure. It's just not there yet, and the amount of work required is too big to "just borrow a few develoeprs and get there. I've also mentioned the possibility of making relatively more of the linux-specific bits open source to get the best of both worlds, but again that's a non-trivial task.

                    The key point here is that a code-shared proprietary driver allows us to write the 3D code once and use it across multiple OSes, while providing the same functionality and performance on an open source driver requires doing all the same work again on a separate implementation, and it's a *lot* of work.

                    Originally posted by Drago View Post
                    Tell us, what you think it could be done with currently available information for PM. You said something of AtomBios table interpolation. Explain. This are super honest questions. I am not trying to argue with you, by no means.
                    Pretty simple. Right now some users can get by with current power management and others can not, and the difference often seems to depend on whether those users have working "low" and "mid" entries in the power tables.

                    Everyone would benefit from full dynamic power management and that's what we're working on, but we knew that would take time. I felt that in the meantime it would be possible to make some reasonable guesses for "mid" values on cards which didn't have those entries, so at least everyone would be at the same level rather than the current state.

                    The trap everyone falls into is thinking that it's an either-or choice, ie working on a short term solution delays a better long term solution. It would if the work was being done by the same people (and that's why I didn't ask our devs to work on improved static PM, or at least didn't push very hard), but community work on static PM would not slow down AMD work on dynamic PM.

                    Dave's main point (which was correct) was that community work on static PM *would* slow down work on other areas where the work would not be throwaway; he weighted the "throwaway" aspect a bit more highly than I did which is totally fair.
                    Last edited by bridgman; 18 January 2013, 11:20 AM.
                    Test signature

                    Comment


                    • Better power management should have absolute priority. The APUs, probably AMD's most important products right now, are nearly unusuable with the free drivers due to lack of power management. Not even the profiles work.

                      It's not just that APUs need more energy than they should, they're also limited to a (low) fallback clock, that means practical performance is a fraction of the APU's potential.

                      Comment

                      Working...
                      X