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

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

    Common sense is that the same thing that was true yesterday is probably still true today unless noted, and i have no idea why you think otherwise.

    Can you people guarantee
    Nothing is ever guaranteed. EVER.

    The company could go bankrupt next week and stop supporting the driver immediately.

    But they've shown no sign of doing anything but fully supporting it for years now, and you seem paranoid.
    Last edited by smitty3268; 25 March 2014, 03:00 PM.

    Comment


    • Originally posted by agd5f View Post
      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.
      Ok that covers it.

      Thanks

      Comment


      • And lets hope that someday they might try to replace the blob with the open source driver (maybe one more policy change ).

        One (or two) final question(s).
        Does this link http://xorg.freedesktop.org/wiki/RadeonFeature/ is an "accurate" representation of the gap between gallium and catalyst in terms of features ? And can we say that dynamic power management is complete ? we have seen a lot of benchmarks and reports in phoronix claiming that it is working perfectly but it is still marked as "work in progress". Same for "Hybrid Graphics"

        Many thanks to all you people for taking the time to answer my posts.

        Comment


        • Originally posted by iznogood View Post
          Does this link http://xorg.freedesktop.org/wiki/RadeonFeature/ is an "accurate" representation of the gap between gallium and catalyst in terms of features ? And can we say that dynamic power management is complete ? we have seen a lot of benchmarks and reports in phoronix claiming that it is working perfectly but it is still marked as "work in progress". Same for "Hybrid Graphics"
          .
          Yeah, that's pretty accurate.

          DPM, HyperZ and Hybrid work well for the majority of users, but there are still some cases in which it doesn't quite work properly, so it's not "DONE".

          OpenCL is still work in progress.

          Comment


          • Originally posted by iznogood View Post
            And can we say that dynamic power management is complete ?
            I'll be happy if somebody correct me if I'm wrong, but as I understand one of DPM problem it's that's threat GPUs with same ASIC like they all have reference design.

            In same time different manufacturers might have different cooling systems, frequencies, etc. Catalyst share lot of code with Windows driver so most likely it's have information about this specifics and likely some GPUs will be more power efficient or quiet with proprietary drivers.

            Comment


            • Originally posted by _SXX_ View Post
              I'll be happy if somebody correct me if I'm wrong, but as I understand one of DPM problem it's that's threat GPUs with same ASIC like they all have reference design.
              The driver reads the power state information out the vbios tables, so it does handle board specific configurations. That said there may be board specific quirks missing in certain cases.

              Comment


              • Originally posted by agd5f View Post
                The driver reads the power state information out the vbios tables, so it does handle board specific configurations. That said there may be board specific quirks missing in certain cases.
                Thanks for clarification.

                Comment


                • Some guy on reddit posted very interesting link.

                  Alex Deucher is going to talk about "AMD's New Unified Open Source Driver" on XDC2014 (8-10 October 2014):
                  AMD is moving to unify it's current open and closed source Linux drivers over a common, shared, open source kernel driver.
                  This talk will provide an overview of our plans for the future and the challenges we face as we move forward.

                  Author: Alex Deucher


                  Hopefully there will be video from XDC.

                  Comment


                  • This was a great article

                    It sounds very much like this will fix the issue with driver support entering legacy status. Legacy status is such a dumb idea on Linux because it means that we also have to keep with legacy Xorg and legacy kernels to match.

                    Hopefully if this shim layer can provide a stable layer of abstraction, the "legacy" drivers should continue to work?
                    Cant wait to dig out my old Radeon 9700. That thing was perfect for developing / testing games on low powered hardware

                    Comment

                    Working...
                    X