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

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

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

    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 03:00 PM.

  2. #152
    Join Date
    May 2009
    Posts
    25

    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
    25

    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,926

    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
    168

    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,327

    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
    168

    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.

Posting Permissions

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