Page 16 of 16 FirstFirst ... 6141516
Results 151 to 159 of 159

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

  1. #151
    Join Date
    Oct 2008
    Posts
    3,219

    Default

    Quote 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; 03-25-2014 at 04:00 PM.

  2. #152
    Join Date
    May 2009
    Posts
    28

    Default

    Quote 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

  3. #153
    Join Date
    May 2009
    Posts
    28

    Default

    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.

  4. #154
    Join Date
    Jun 2009
    Posts
    2,933

    Default

    Quote 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.

  5. #155
    Join Date
    Sep 2013
    Posts
    250

    Default

    Quote 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.

  6. #156
    Join Date
    Dec 2007
    Posts
    2,402

    Default

    Quote 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.

  7. #157
    Join Date
    Sep 2013
    Posts
    250

    Default

    Quote 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.

  8. #158
    Join Date
    Sep 2013
    Posts
    250

    Default

    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
    http://www.x.org/wiki/Events/XDC2014/Program/

    Hopefully there will be video from XDC.

  9. #159
    Join Date
    Jul 2012
    Posts
    99

    Default

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •