Announcement

Collapse
No announcement yet.

AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver

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

  • AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver

    Phoronix: AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver

    Alex Deucher of AMD has taken the floor at XDC2014, which got underway today in France to provide an update on the company's new unified open-source driver strategy. Compared to what I originally reported earlier in the year when breaking the news, there's some notable changes but overall this is an exciting endeavor for AMD Linux customers with the open and closed source AMD GPU drivers going to share the same (open-source) Linux kernel driver.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Holy shit, finally some good news! It would be very interesting to know if they plan to enlarge their FOSS team.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #3
      This driver model still seems a bit inflexible. Imagine NVIDIA doing the same thing. They could roll out a new version of their closed source OpenGL implementation easily, which is good, but other features (think G-Sync etc.) are bound to the kernel version and release schedule (and indirectly the schedule of distros). On Windows AMD and NVIDIA can just roll out stuff whenever they want and it just works. Companies need a direct path to their users/customers and the OS and distros should not get into their way like this.
      Last edited by blackout23; 08 October 2014, 10:08 AM.

      Comment


      • #4
        I think this way could be better for their Linux drivers in the long run. However, I am concerned that if the Windows and Linux drivers won't share the same code, features won't be implemented in the Linux drivers and it will just add another driver to support with it's own idiosyncrasies. Supporting another driver code base might be too expensive for AMD unless they get a lot of outside help from the community.

        Comment


        • #5
          Originally posted by blackout23 View Post
          This driver model still seems a bit inflexible. Imagine NVIDIA doing the same thing. They could roll out a new version of their closed source OpenGL implementation easily, which is good, but other features (think G-Sync etc.) are bound to the kernel version and release schedule (and indirectly the schedule of distros). On Windows AMD and NVIDIA can just roll out stuff whenever they want and it just works. Companies need a direct path to their users/customers and the OS and distros should not get into their way like this.
          I think that's a distro's problem, if companies join a FOSS model (more tied to Linux kernel development), newer hardware that is not available in the market will reach to the Linux kernel faster, before user can actually buy the hardware (like what Intel is doing for its next generation of CPUs). In that case, users will need some love from the distributions to get updated with latest kernels faster.

          Comment


          • #6
            Originally posted by blackout23 View Post
            This driver model still seems a bit inflexible. Imagine NVIDIA doing the same thing. They could roll out a new version of their closed source OpenGL implementation easily, which is good, but other features (think G-Sync etc.) are bound to the kernel version and release schedule (and indirectly the schedule of distros). On Windows AMD and NVIDIA can just roll out stuff whenever they want and it just works. Companies need a direct path to their users/customers and the OS and distros should not get into their way like this.
            Did you ever hear about DKMS?
            ## VGA ##
            AMD: X1950XTX, HD3870, HD5870
            Intel: GMA45, HD3000 (Core i5 2500K)

            Comment


            • #7
              Originally posted by darkbasic View Post
              Did you ever hear about DKMS?
              What do you need DKMS for, when you have a kernel driver mainlined?

              Comment


              • #8
                If they supported current gen HW I would be really happy.
                I don`t want to have to upgrade my R9 290 nor R7 260.

                Comment


                • #9
                  Originally posted by blackout23 View Post
                  This driver model still seems a bit inflexible. Imagine NVIDIA doing the same thing. They could roll out a new version of their closed source OpenGL implementation easily, which is good, but other features (think G-Sync etc.) are bound to the kernel version and release schedule (and indirectly the schedule of distros). On Windows AMD and NVIDIA can just roll out stuff whenever they want and it just works. Companies need a direct path to their users/customers and the OS and distros should not get into their way like this.
                  You call it "distro getting in the way", I call it "assurance that some brainfart by some of their employees doesn't crash my kernel".

                  Comment


                  • #10
                    Originally posted by BreezeDM View Post
                    I think this way could be better for their Linux drivers in the long run. However, I am concerned that if the Windows and Linux drivers won't share the same code, features won't be implemented in the Linux drivers and it will just add another driver to support with it's own idiosyncrasies. Supporting another driver code base might be too expensive for AMD unless they get a lot of outside help from the community.
                    From what I understand, the existing Catalyst kernel driver and X.org driver are the few things that aren't shared with the Windows/Mac driver. So the GL compiler, CL runtime, CL Compiler, etc for Catalyst will still be sharing code with the windows driver, but the kernel/X.org drivers which were custom for *NIX anyway will now be sharing development with the open-source driver.

                    So what used to be shared with windows will still be shared, and the open-source drivers will now get to share some (more?) development resources with the closed driver.

                    EDIT: And now that I think of it, this might also open up the way to Catalyst on BSD.

                    Comment

                    Working...
                    X