No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    This week I was out at the Game Developer's Conference not with a focus on games but to learn about some changes they AMD currently pursuing for their Linux driver model. If this new Linux driver model goes through, the Catalyst Linux driver will be more open, but it's not without some risk. Read more in this Phoronix exclusive story.

  • #2
    Great story! That's what I'm looking for when checking out Phoronix every day.


    • #3
      This is some really interesting news, and not something I expected at all. I think it sounds like a pretty good plan, though honestly I think it'd be perfectly fine to make the FOSS drivers keep up with catalyst and then just ditch catalyst altogether.

      I'm really happy AMD is putting this much attention and effort into Linux. They'll eventually become the most recommendable graphics solution if they keep it up.


      • #4
        Personally, I think that most of Michael's concerns are not as problematic as it sounds like, and that this approach is very much doable (and beneficial due to no more duplication of work and the merge of existing features in both kernel drivers).

        Really exciting stuff.


        • #5
          Excellent article Michael!


          • #6
            In the interest of transparency, AMD sponsored the Phoronix trip to GDC 2014 in order to meet-up and talk about their Linux plans.
            AMD dont give cards (hopefully in future send cards as nvidia) but help with your trip cost, very impressive AMD

            Hopefully AMD continues put attention on phoronix

            Good article

            Last edited by pinguinpc; 03-22-2014, 12:06 PM.


            • #7
              Originally posted by pinguinpc View Post
              AMD dont give cards...
              In fairness, we did send a Kaveri system. Not a "card" technically, but it is hardware


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


                • #9
                  If they manage to do that, it would be great.

                  They would benefit from recent and incoming features to the Radeon DRM kernel driver: Primes fds, dma-buf fences, etc.
                  And it would become much easier for Wayland support.

                  Also I think it would be easier for them to have enduro support like on Windows.


                  • #10
                    Originally posted by bridgman View Post
                    In fairness, we did send a Kaveri system. Not a "card" technically, but it is hardware
                    bridgman - I figure you have a unique perspective due to having worked with the open source driver for quite a while. How do you feel about this development? What are your thoughts on having a Catalyst user space interacting with the open source radeon DRM?

                    One of the things I took from the article it sounds like Michael had concerns in AMD possibly needing to rework parts of the DRM component of the open source driver to interact with Catalyst down the track and this potentially being an issue being accepted upstream if changes become extensive. Do you think this could be an issue?

                    Any other comments on the article?


                    • #11
                      I have to say, i didn't expect this at all.

                      Im using a notebook with AMD/ATI Graphics (yes, it is labeled like this ), a tm2 the only convertible with a good graphics card (beside the Vaio Flip 15 which has poor battery time).
                      In the past 1 - 2 years my hardware was "magically" getting better and better.

                      At the moment (especially reading this article) I have a doubt about buying NVidia hardware. My experience with this AMD Graphics card is just overwhelming.
                      If AMD really has the will and patience to pull this through, I'm very impressed and one point less to look at NVidia


                      • #12
                        One of the big reasons for not open-sourcing Catalyst remains concerns about AMD's "secret sauce" within their OpenGL driver code in having a competitive advantage with having some hot optimizations within the driver and other novel code that they would prefer their competitors to not see or utilize.
                        Highly doubt that NVIDIA is interested in AMDs OpenGL "secret sauce" since they clearly don't need it. AMD doesn't have a competitive advantage over NVIDIA when it comes to OpenGL so what's there to lose?


                        • #13
                          Thats very nice to hear. Does this also mean you could use both drivers in parallel? Like use mesa for normal desktop and catalyst for games?
                          Also .. glamor on catalyst (kms + opengl) .. no more annoying fglrx X driver.


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


                            • #15
                              Last time I looked at fglrx kernel blob in debugger, there were a lot of c++ mangled symbols. So first if they want to modify foss radeon kernel module, adding code from fglrx and then push changes upstream, they have to rewrite kernel c++ code to c. Linus will never accept c++ in kernel...