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

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

    Comment


    • #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?

      Comment


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

        Comment


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

          Comment


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

            Comment


            • #16
              Also expressed was that AMD doesn't have much to gain from a business perspective in open-sourcing the Catalyst code-base.
              While that may technically be true.. they would have a MASSIVE gain in terms of sales/business and user confidence if they did open source most or completely remove the need for a binary blob in terms of hardware driving capability. If they could actually work on the kernel driver to make it damn near 95-100% capable with only using the catalyst GUI to do all the tuning in a nice GUI friendly way (plus any weird special things they want up there that really doesn't need to be down in the kernel) then they would gain not only me as a customer, but I imagine at least hundreds of thousands of customers whom use similar methods of deciding on hardware purchases.
              Last edited by HeavensRevenge; 03-22-2014, 12:49 PM.

              Comment


              • #17
                Linux is also used in a lot of computing environments. Having a worse driver and support is not a good thing.
                Doing this would give them more opportunities in high performance Linux environments.

                Comment


                • #18
                  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.
                  What about Intel? AFAIK Intel graphics driver is totally open. Does Intel has any disadvantages right now because of this?
                  I can't see why AMD don't drop Catalyst and put efforts just in Radeon. Maybe something related to DRM (Digital Management Rights). Anyway, it's a good step in the ridht direction.

                  Comment


                  • #19
                    If i read that rigth AMD will have an unified graphics kernel driver and the radeon-kdf driver for hsa? or whers stands the radeon-kdf driver in the amd open linux driver picture?

                    radeon-kdf

                    The kernel image is built from a source tree based on the 3.13 upstream release plus :

                    an updated kernel graphics driver ("radeon") including initial dpm support for Kaveri and an interface to support sharing hardware resources with the HSA kernel driver.
                    A new HSA kernel driver ("radeon-kfd") which works with the radeon graphics driver.
                    Fixes and improvements to the amd_iommu(v2) drivers, mm and mmu_notifier code.
                    ???

                    Comment


                    • #20
                      Originally posted by rudregues View Post
                      I can't see why AMD don't drop Catalyst and put efforts just in Radeon.
                      @bridgman answered on it already as well as other developers: professional graphics and workstations.
                      They can't just go and drop support for systems that will never updates for open source drivers stack.

                      Comment

                      Working...
                      X