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 spstarr View Post
    Why would AMD spend millions on focused on a binary driver costing the company time/effort and lots of money when they could just get open source people to work on a driver and some AMD developers?
    Because that binary driver runs on Windows.

    The Linux-specific parts of fglrx are very few. Most of the blob is the same as the Windows driver. And they can't stop making the windows driver, obviously.

    Comment


    • Right. If we had been writing a separate Linux driver (rather than code sharing) it would be open source.

      One thing I've said a lot of times is that ability to share code across multiple OSes is the primary reason for proprietary drivers to exist.

      You pretty much have to take the secrecy requirements of all the OSes sharing code and follow the most restrictive of them all, which is how shared-code drivers like Catalyst Linux (and the corresponding NVidia drivers) end up being proprietary. We are the only vendor willing to support both proprietary drivers (for workstation and other performance-critical markets) AND open source drivers.

      Note that the 3D workstation drivers have historically been associated with high end GPUs, which we make but not everyone does. If we hadn't made big-ass GPUs we probably wouldn't have needed a workstation driver in the past. Things are getting interesting now because high end APUs (eg Trinity/Richland) have enough HW performance to be viable at the low end of the workstation market, given the right drivers.
      Last edited by bridgman; 01-17-2013, 11:50 AM.

      Comment


      • I know what the responses will be, but I'm gonna say it anyway.

        I think AMD needs to hire more OSS developers. The ones they have are doing a fantastic job, but there just aren't enough of them to tackle the numver of issues.You guys claim that with more developers you'll start having issues with them stepping on each others toes but I disagree. If it was managed in such a way that each was asigned a task in something resembling a pipeline with quality control and legal review incorporated into that pipeline it would seem to be a better solution. You could add as many developers as you need.

        Even if you don't hire more developers you DO need to start implementing timeline based feature releases. You guys of all people know how processing works. Your development cycles could benefit from a process that resembles a pipeline.
        Last edited by duby229; 01-17-2013, 12:12 PM.

        Comment


        • Originally posted by duby229 View Post
          IYou guys claim that with more developers you'll start having issues with them stepping on each others toes but I disagree. If it was managed in such a way that each was asigned a task in something resembling a pipeline with quality control and legal review incorporated into that pipeline it would seem to be a better solution.
          Don't think we have ever said that.

          Remember the idea was "we provide info, community writes the driver", not "AMD writes the driver".

          Originally posted by duby229 View Post
          Even if you don't hire more developers you DO need to start implementing timeline based feature releases. You guys of all people know how processing works. Your development cycles could benefit from a process that resembles a pipeline.
          Don't understand this. We run on the common kernel and mesa development cycles. The X driver releases are aligned with kernel & mesa, but the X driver doesn't change much these days since most of the code is now in the kernel.

          Comment


          • Originally posted by bridgman View Post
            Right. If we had been writing a separate Linux driver (rather than code sharing) it would be open source.

            One thing I've said a lot of times is that ability to share code across multiple OSes is the primary reason for proprietary drivers to exist.

            You pretty much have to take the secrecy requirements of all the OSes sharing code and follow the most restrictive of them all, which is how shared-code drivers like Catalyst Linux (and the corresponding NVidia drivers) end up being proprietary. We are the only vendor willing to support both proprietary drivers (for workstation and other performance-critical markets) AND open source drivers.

            Note that the 3D workstation drivers have historically been associated with high end GPUs, which we make but not everyone does. If we hadn't made big-ass GPUs we probably wouldn't have needed a workstation driver in the past. Things are getting interesting now because high end APUs (eg Trinity/Richland) have enough HW performance to be viable at the low end of the workstation market, given the right drivers.
            I've seen some numbers recently on workstation GPU market, and AMD isnt doing very well there. FGLRX isnt stable and most folks who use linux know that. They stay away from it like it was a plague. I think you'd be much better off putting your resources into the OSS side of the equation. At the very minimum it is stable. It just needs support for the features that the hardware provides.

            And despite what you say I don't think DRM on linux is even an issue at all. I'm convinced that anybody who uses linux in the first place doesnt care one tiny little bit about DRM, otherwize they wouldnt be using linux. They only things that implement DRM is the proprietary drivers and EVERYTHING else circumvents it. I can't name a single proprietary video player that works well on linux. All of the OSS players are able to work by circumventing DRM.

            I think DRM is nothing more than an excuse.

            Comment


            • Originally posted by duby229 View Post
              And despite what you say I don't think DRM on linux is even an issue at all. I'm convinced that anybody who uses linux in the first place doesnt care one tiny little bit about DRM, otherwize they wouldnt be using linux. They only things that implement DRM is the proprietary drivers and EVERYTHING else circumvents it. I can't name a single proprietary video player that works well on linux. All of the OSS players are able to work by circumventing DRM.

              I think DRM is nothing more than an excuse.
              What do you think I said.

              One more time, nobody is saying that DRM is required on Linux (although it probably will be on Android). The issue is that DRM *is* a requirement on the other OSes which share code with fglrx, and the DRM requirements of *those* systems are why fglrx needs to stay binary-only.

              Comment


              • Originally posted by bridgman View Post
                Don't think we have ever said that.

                Remember the idea was "we provide info, community writes the driver", not "AMD writes the driver".



                Don't understand this. We run on the common kernel and mesa development cycles. The X driver releases are aligned with kernel & mesa, but the X driver doesn't change much these days since most of the code is now in the kernel.
                Please don't get me wrong, I'm very pleased with the OSS drivers, and developers like Marek and Arlied who have the skill to do the actual programming are doing it. It's just that however unfortunate it is developing drivers for GPU's is difficult and complex and very few people have the knowledge and skill set to do it. My point is that FGLRX is a pile of steaming crap. As it stands if AMD wants a -good- driver the OSS one is a much better point to start from. At least there you'll have a known stable base to build on.

                And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.

                Comment


                • Originally posted by bridgman View Post
                  What do you think I said.

                  One more time, nobody is saying that DRM is required on Linux (although it probably will be on Android). The issue is that DRM *is* a requirement on the other OSes which share code with fglrx, and the DRM requirements of *those* systems are why fglrx needs to stay binary-only.
                  But not for linux. So exactly what is the point in sharing code for linux when that code isnt needed or wanted or used on linux?

                  Like I said DRM sounds like a big fat excuse.

                  Comment


                  • Originally posted by duby229 View Post
                    And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.
                    As has been stated previous on a number of occasions, certain features (like UVD) might not be able to be released at all, so we can't target a particular timeline when it's not clear whether that feature will be able to be released at all. We can't speak to when/if something like UVD will be released until all the internal discussions have been resolved and we can say yes or no.

                    Comment


                    • Originally posted by duby229 View Post
                      But not for linux. So exactly what is the point in sharing code for linux when that code isnt needed or wanted or used on linux?

                      Like I said DRM sounds like a big fat excuse.
                      Most of the code is shared (modesetting, 3D, multi-media, etc.), not just the DRM related code. Unfortunately, DRM pervades a lot of it so you would effectively have to maintain two trees one with DRM, one without. That kind of defeats the purpose of code sharing.

                      Comment


                      • Originally posted by duby229 View Post
                        Please don't get me wrong, I'm very pleased with the OSS drivers, and developers like Marek and Arlied who have the skill to do the actual programming are doing it. It's just that however unfortunate it is developing drivers for GPU's is difficult and complex and very few people have the knowledge and skill set to do it.
                        Ahh, so you want to change the deal and have us fund a lot more of the open source driver work. Guess you never watched Transporter

                        Originally posted by duby229 View Post
                        My point is that FGLRX is a pile of steaming crap. As it stands if AMD wants a -good- driver the OSS one is a much better point to start from. At least there you'll have a known stable base to build on.
                        Remember that fglrx is judged internally against 3D workstation requirements (slow changing enterprise distros, no compositors, very strong 3D focus). Consumer and business client requirements are different and I agree the open source driver is a better fit there.

                        Originally posted by duby229 View Post
                        And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.
                        OK, so you're talking about release of programming information not development. Totally different.

                        Remember that we said from the start we were *not* committing to release UVD information, so knock that off your list. I did commit to *trying* and we are making progress there, so complaining that "it's been missing for years" and blaming process is kinda missing the point.

                        Power management a bit different but not much -- it went from being "trivial" to "really complex" while we were focused on getting caught up with display/2D/3D driver functionality. We didn't catch that in time (my fault) but have been working on it pretty hard and making good progress. Again, remember that as hard as writing the code is, releasing the programming info is even harder.
                        Last edited by bridgman; 01-17-2013, 12:53 PM.

                        Comment


                        • Originally posted by duby229 View Post
                          But not for linux. So exactly what is the point in sharing code for linux when that code isnt needed or wanted or used on linux? Like I said DRM sounds like a big fat excuse.
                          Huh ?? Are you possibly thinking that DRM is an isolated little piece of the driver stack ? If so, please understand that it's not like that at all.

                          Comment


                          • Originally posted by duby229 View Post
                            And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.
                            MESA OpenGL level has progressed.
                            AMD attitude has not
                            They are straight, completely driver-type agnostic, highly passive player unless you bribe($$$) them
                            Current bribe list:
                            - microsoft ($$$$$$$)
                            - hollywood ($$$$$)

                            Ask yourself, how can you build anything stable on unstable ground?

                            There is also very high probability that (should AMD hardware be released) Android driver will be
                            - DRMed
                            - closed source
                            - financed as seperate entity, cannibalizing on Linux stack

                            :begin subliminal message:
                            And BTW, your arguing has no use, because you will not be given answers, but excuses.
                            If you want your arguing to have response and attitude as if you are customer, buy Windows
                            They know how to make open Linux driver better, not you Linux user
                            :end subliminal message:

                            Comment


                            • Well, I just want to say thank you. I disagree with you completely on DRM and FGLRX, but there is nothing I can do about it.

                              Please don't misunderstand, I think you guys are doing a fantastic job. And it is good to hear that power management work is coming along. I know that UVD is probably never going to be supported and that when OpenCL gets into a better state at that point an opencl video decoder will be attempted.

                              Comment


                              • Originally posted by agd5f View Post
                                Most of the code is shared (modesetting, 3D, multi-media, etc.), not just the DRM related code. Unfortunately, DRM pervades a lot of it so you would effectively have to maintain two trees one with DRM, one without. That kind of defeats the purpose of code sharing.
                                I'm saying the should eliminate fglrx completely and maintain zero trees.

                                Comment

                                Working...
                                X