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.

    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; 01-18-2013, 12: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; 01-18-2013, 01:41 AM.

          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; 01-18-2013, 02: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; 01-18-2013, 05: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; 01-18-2013, 09:47 AM.

                  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; 01-18-2013, 10:20 AM.

                    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


                      • ... aaaaand this gets back into the question of "what do you mean by better" ? Improved static PM (which is more of a challenge for APUs), or just keep pushing on advanced DPM and hope we can release that ?

                        Right now we're focusing on advanced DPM as a priority but that just means it makes progress, doesn't guarantee it will happen or make it happen "real fast".

                        Comment


                        • Originally posted by BO$$ View Post
                          Money is not an instrument to provide innovation and commonwealth of the society. Money is any object or record that is generally accepted as payment for goods and services and repayment of debts in a given socio-economic context or country. The main functions of money are distinguished as: a medium of exchange; a unit of account; a store of value; and, occasionally in the past, a standard of deferred payment.[From Wikipedia]

                          (1)A company's purpose is to maximize the shareholders' wealth. Right now AMD already has a driver called fglrx. Probably it's core is shared between linux and windows and only provides a wrapper for some generic functions that are implemented differently on windows and linux. For some people (maybe a lot I don't know I'm not one of them) the fglrx has problems. So AMD should focus on solving those problems. Not rewriting from scratch and open source driver. I understand that an open source driver would be better from Stallman's view but remember (1). Reimplementing that driver in open source is probably a gargantuan task. You may say that why don't they open source their current fglrx driver. Maybe because they have a lot of code that isn't theirs and can't open source it.

                          New drivers for new devices should start as open source but right now some drivers are proprietary and we should accept that. They won't become open source. So, in order to attract a larger userbase, we must present compelling arguments for them to move to linux. One compelling argument is that you can have the same graphics performance on both windows and linux. The argument that open source is better but still 50-80% (you're very optimistic this is not what I see in practice) of the performance turns a lot of people off. In fact even though everybody agrees that open source is better in theory, right now they will have the fglrx driver thank you very much. So AMD should focus on providing value to the customer. And most customers don't care if it's open source or not, but care if it's fast or not. And for them it's easier (I think) to fix the fglrx than to rewrite it.

                          However, once Siri was purchased by Apple, Apple restricted its usage only to own platform. This is damaging illegal method of "exclusivity".

                          What about Apple's freedom to do what they want with their products? Who made you god to say on which platforms should Siri be available. Ever thought that they did it only for Apple because of limited resources allocated for that project? Why should they have made it available for other platforms if it didn't guarantee revenue? Remember (1). Always remember (1). And no I don't like Apple and never liked Steve Jobs, never owned something from Apple.

                          In this case, opensourcing the driver will produce vast platform advantage and compatibility of AMD solutions to all current and future systems.

                          Agreed. But only if open source programmers take it and improve it. There is no guarantee that people will work on it. Not everybody is a graphics driver programmer you know. AMD should make something of a survey to find out how many people are actually willing to work on their driver.


                          Where did you ask? In a pool of clueless people? To provide educated opinion, one should know BOTH ways equally good.
                          You asked sheep. Recieved "Meee". Now you claim "Meee" to be the ultimate answer. Meee don't think so.

                          Yes clueless people. The kind of clueless people that use windows and don't care about linux but the linux community wants them to take on linux. That kind of people. The potential customers if you wish. They aren't sheep. Do you think Microsoft calls its customers sheep because they can't do kernel programming? And they don't care about open source. They first and foremost care if they can do in linux what they can do in windows equally easier or even easier. And right now, since they don't have the same performance with the radeon driver they will go with the proprietary ones. They may be sheep from your point of view, but I call them normal people for going with the performance. Again, after explaining open source they agree that it's a better development model, but they still choose performance and functionality first. That is why AMD should focus on making sure that fglrx works. And the X.org guys can help the AMD guys by not changing the interface so much so that people could use the end of life driver version indefinitely(talking about the 2000 3000 and 4000 lines that no longer work with the latest X.org).

                          I feel that the linux community says that they want better market share but aren't actually willing to do what is necessary to get that market share. And when they don't get it they call everybody sheep and narrow minded for not bending to their way of doing things. If the purpose is to get as much market share as possible we should focus on what people want. Not on what Stallman wants.

                          You said alot here, and I don't want to address all of it. Instead I'll just state my opinion as an opposite.

                          If AMD wants to waste their time developing it that is perfectly fine, they can choose to do so. The problem with it is that it is unstable. It crashes on just abou every computer it runs on. Release cycles are not coordinated with new x server and kernel releases. Commonly used hardware is only supported by old drivers that only work on old x servers. Shaders are not rendered properly. There is no possibility of kernel mode setting. It uses its own graphics stack so it doesnt contribute to the linux ecosystem..... And the list of problems goes on. I'm not saying that a proprietary driver can't be good because it can. But I am saying that fglrx is -not-...

                          At least the OSS drivers have none of these problems. It may be incomplete, but at least it works on far more hardware than current fglrx and is stable with zero configuration requirements.
                          Last edited by duby229; 01-18-2013, 12:54 PM.

                          Comment


                          • @BO$$
                            You want Linux as other windows, but you want it to be same windows. Like your effort to duplicate already existing proprietary driver, it possess no uniqueness and will fail.
                            Performance/features of software are based only upon amount of human/hours(effort) devoted to it, like I claimed it has nothing to do with wither its opensource or closed source.
                            Given equilibrium in effort, opensource driver is many times more advanced to a proprietary driver, in value, adaptability and development efficiency. And you are not bound to ugly windows 8 squares.

                            Ok, but we don't have that equilibrium above because the company in question distributes the effort differently, so you think its because opensource is inefficient. Thats not the case.
                            The truth is that you can't drive maglevs on steam trains' railway. It won't work.

                            And they also have this microsoft agreement, which means they would implement everything microsoft wants them to, than what customers want them to.
                            So if customers run off microsoft (what they usually do), its their primary job to offer sub-class broken maglev in order to bullcrap them back. Because old railway is everywhere and microsoft holds its monopoly.
                            Also they would rather replace the railway with that of microsoft, preferably patented and preferably again microsoft-only. If you don't believe me, check MS JPEG replacement format - JPEG XR. A "standard" that is windows-only and distributed under "open agreement" that prohibits copyleft.

                            So, lets replace electromagnetic drive with that from the steam loc and call it a day!

                            Picture gallery:

                            FGLRX:


                            AMD (Bridgeman's) viewpoint:


                            Opensource as it should be:


                            Opensource by AMD:


                            PS.
                            Why comparing opensource to maglev and proprietary to steam train?
                            Easy, magnetic rail has no proprietary rut, its free floating. And its roll friction is nearly zero, because there is no license fees.

                            Comment


                            • Were these people insane before coming here, or did phoronix do this to them???

                              Comment


                              • Originally posted by crazycheese View Post
                                Picture gallery:

                                FGLRX:


                                AMD (Bridgman's) viewpoint:


                                Opensource as it should be:


                                Opensource by AMD:

                                Hilarious! Make this a sticky post!

                                Comment

                                Working...
                                X