Announcement

Collapse
No announcement yet.

AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy

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

  • This article made me eye that R9 270x ... nah j/k I was planning to get it anyway!

    Comment


    • Thanks, you summarized it well.

      Originally posted by smitty3268 View Post
      No change to Mesa was discussed here, so the same things that are going on now will continue to go on, just as they have been.
      Exactly! We are not reducing our efforts on the open source stack. There will be more collaboration between the teams which will benefit both stacks.

      Comment


      • Originally posted by entropy View Post
        @@twriter, @Bridgman, @agd5f
        Can you share something about the "planned" transition process?
        Sorry, as you speculated, it's too early to share those details.

        Comment


        • Originally posted by smitty3268 View Post
          Come on, read the article and use some common sense.


          Nothing. No change to Mesa was discussed here, so the same things that are going on now will continue to go on, just as they have been.


          They already are, through their OSS team. There was no change to that being discussed anywhere, so there would still be a separate OSS team working on Mesa, and closed source team working on fglrx userspace. They'd just share the same kernel driver.


          For desktop users, yes. For AMD's commercial clients, no. At least not yet.


          According to the article - which you should have read - there are not. They are all in the userspace code.


          Exactly because of that. It's only now that the radeon kernel driver is in good enough shape that they can consider using it. Perhaps in the future the userspace side of the driver will become good enough they can use that, too, and just drop fglrx entirely on linux, but it isn't there yet like the kernel portion is.


          No, and such a thing was never mentioned, or even slightly hinted at anywhere at all. I have no idea where you are getting such ideas from.
          Common sense is that when AMD has a working userspace catalyst driver will stop all with the open source mesa/gallium module just to save money and intellectual property. Why support the other half of the stack when they can use the closed source one ? I read the article and comments, I am just not convinced after knowing how companies work

          However if this does not go that way then this is an amazing turn off events that will benefit everyone
          Last edited by iznogood; 03-25-2014, 03:06 AM.

          Comment


          • Originally posted by iznogood View Post
            Common sense is that when AMD has a working userspace catalyst driver will stop all with the open source mesa/gallium module just to save money and intellectual property. Why support the other half of the stack when they can use the closed source one ?
            If the OSS radeon driver (not the kernel part) would die, then fglrx would be the only user of the radeon kernel part. Thus, the radeon driver would have to be removed, as the open driver parts for binary blobs are not allowed in the kernel.

            Comment


            • Originally posted by iznogood View Post
              Common sense is that when AMD has a working userspace catalyst driver will stop all with the open source mesa/gallium module just to save money and intellectual property. Why support the other half of the stack when they can use the closed source one ? I read the article and comments, I am just not convinced after knowing how companies work

              However if this does not go that way then this is an amazing turn off events that will benefit everyone
              They already have working drivers, so if your prediction would be true they already would have stopped development of one of them two save money. Would be much easier, since they would also save the development time that is necessary for the transition.
              Besides that, how could they stop development of the free driver? Even if they fire the open source developers I bet the driver would be continued by volunteers, in the same way the nouveau team works.
              Last edited by Vim_User; 03-25-2014, 06:27 AM.

              Comment


              • Originally posted by iznogood View Post
                Common sense is that when AMD has a working userspace catalyst driver will stop all with the open source mesa/gallium module just to save money and intellectual property.
                Fortunately then, "common sense it not so common." Just as we have workstation customers that need the features and performance of the Catalyst driver, we need the open source stack to service others. Embedded customers use a huge variety of Linux variants and it's difficult to support them all using closed source. The open source drivers are not going away.

                Comment


                • This might fix even older AMD GPUs

                  With a common DRM driver, GPU resets for us older R600 cards might be fixed if fglrx's kernel bits fold into the radeon DRM driver this is something I hope can happen. I can't just replace my laptop GPU you know, stability has been a big issue for me on my RV635 and perhaps fglrx's kernel has some errata/workarounds.

                  I wonder, shouldn't AMD let the FLOSS AMD employees see fglrx's kernel driver directly instead of keeping the teams separate? Or they do?

                  Shawn

                  Comment


                  • Originally posted by entropy View Post
                    Great article, Michael!

                    This comes totally unexpected, indeed.

                    Besides the risks, this sounds exciting! I just love people and companies
                    that are brave enough to rethink their previously made decisions.
                    AMD were among the first to release detailed (and useful) programming
                    docs for GPUs and this might be another groundbreaking thing.
                    You do know that this documentation thing was as the SuSE guys (egbert and I) proposed to AMD, right?
                    You also do know that Mr Bridgman did not release all the documentation he handed us, contrary to our agreement?
                    You also do know that documentation stopped in february 2008, when AMD ran out of money and the work with SuSE discontinued? (only recently did some documentation seep out again).
                    And before you say "But,", you should also know that the Instruction Set Architecture documents were not released by Mr Bridgman, but were released by the AMD GPGPU guys, a team which was wholly separate from ATI in late 2007 already.

                    Comment


                    • Originally posted by ricequackers View Post
                      Sounds promising, but it must be mentioned that the #1 reason that graphics on Linux is a mess (especially on the ARM side of things) is because though the engineers would be more than happy to open-source (or at least open up) their drivers, but the suits above them are absolutely scared that doing so would reveal the secret sauce of their GPUs. Still, attitudes do vary - ARM is trying to encourage partners to open up and has been leading by example with Mali. At the other end of the scale, you have Imagination where practically everything is a black box. They're starting to improve now, for Rogue we now have actual block diagrams and what each USC actually has, but there's still a long way to go.
                      WTF? ARM is discouraging open source with Mali. Stop doing those drugs.

                      Comment


                      • People might want to read the original proposal written by Egbert, Emmes and myself, which started this whole open source strategy, and which pushed ATI to a point where they couldn't backtrack anymore.

                        http://www.phoronix.com/scan.php?pag...nhd_four&num=6

                        You might want to consider the bit:
                        "AMD may additionally provide 3D shader optimization in an encapsulated module that can be dynamically loaded into libGL."

                        We wanted fglrx to turn into a module with solid, opensource: modesetting/display, 2D support, Media support and basic 3d support. But Mr bridgman had other plans, and helped foster competing projects, and only released Docs as far as he was forced to by AMD (which died the second AMD ran out of money).

                        Now, about the future: you will not get fglrx running on top of KMS. You will also not get it working with Mesa or other things. The kernel driver will, _at_ _most_, be moulded into a form where fglrx can make use of some shared in kernel memory management. I doubt command submission/CP will even be shared.

                        Comment


                        • Originally posted by libv View Post
                          Now, about the future: you will not get fglrx running on top of KMS.
                          You will also not get it working with Mesa or other things. The kernel driver will, _at_ _most_,
                          be moulded into a form where fglrx can make use of some shared in kernel memory management.
                          I doubt command submission/CP will even be shared.
                          I expected to have exactly that shared...
                          Why else would AMD share the drm kernel part?

                          DISCLAIMER: I'm not an expert.

                          Comment


                          • Oh boy. When reading the article I thought "libv is going to see this eventually..." and so he did, as grumpy about it as ever

                            Comment


                            • Fortunately then, "common sense it not so common." Just as we have workstation customers that need the features and performance of the Catalyst driver, we need the open source stack to service others. Embedded customers use a huge variety of Linux variants and it's difficult to support them all using closed source. The open source drivers are not going away.
                              Ok, I get that. But in recent years the open source driver got most features one way or the other.
                              Can you people guarantee that the gallium driver will be treated as a first class citizen and still get all the features/docs or it will be used only as a fallback in cases catalyst can not be used?
                              If people expect the community to take over the development (as suggested in a post) then this would be a huge step in the wrong direction in my opinion.

                              If I miss something then I apologise

                              Comment


                              • Originally posted by iznogood View Post
                                Ok, I get that. But in recent years the open source driver got most features one way or the other.
                                Can you people guarantee that the gallium driver will be treated as a first class citizen and still get all the features/docs or it will be used only as a fallback in cases catalyst can not be used?
                                If people expect the community to take over the development (as suggested in a post) then this would be a huge step in the wrong direction in my opinion.

                                If I miss something then I apologise
                                As stated on many occasions previously in this thread, the open source user-mode gallium drivers are not going anywhere and will continue to be developed by AMD in the same manner as they are today. We have customers where open source is a requirement and we have customers where the workstation features of catalyst are a requirement.

                                Comment

                                Working...
                                X