Page 15 of 16 FirstFirst ... 513141516 LastLast
Results 141 to 150 of 157

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

  1. #141
    Join Date
    Jan 2013
    Posts
    1,116

    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
    They already have working drivers, so if your prediction would be true they already would have stopped development of one of them two save money. Would be much easier, since they would also save the development time that is necessary for the transition.
    Besides that, how could they stop development of the free driver? Even if they fire the open source developers I bet the driver would be continued by volunteers, in the same way the nouveau team works.
    Last edited by Vim_User; 03-25-2014 at 06:27 AM.

  2. #142
    Join Date
    Feb 2011
    Location
    Toronto, ON, Canada
    Posts
    31

    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.
    Fortunately then, "common sense it not so common." Just as we have workstation customers that need the features and performance of the Catalyst driver, we need the open source stack to service others. Embedded customers use a huge variety of Linux variants and it's difficult to support them all using closed source. The open source drivers are not going away.

  3. #143
    Join Date
    May 2010
    Posts
    20

    Default This might fix even older AMD GPUs :D

    With a common DRM driver, GPU resets for us older R600 cards might be fixed if fglrx's kernel bits fold into the radeon DRM driver this is something I hope can happen. I can't just replace my laptop GPU you know, stability has been a big issue for me on my RV635 and perhaps fglrx's kernel has some errata/workarounds.

    I wonder, shouldn't AMD let the FLOSS AMD employees see fglrx's kernel driver directly instead of keeping the teams separate? Or they do?

    Shawn

  4. #144
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    323

    Default

    Quote Originally Posted by entropy View Post
    Great article, Michael!

    This comes totally unexpected, indeed.

    Besides the risks, this sounds exciting! I just love people and companies
    that are brave enough to rethink their previously made decisions.
    AMD were among the first to release detailed (and useful) programming
    docs for GPUs and this might be another groundbreaking thing.
    You do know that this documentation thing was as the SuSE guys (egbert and I) proposed to AMD, right?
    You also do know that Mr Bridgman did not release all the documentation he handed us, contrary to our agreement?
    You also do know that documentation stopped in february 2008, when AMD ran out of money and the work with SuSE discontinued? (only recently did some documentation seep out again).
    And before you say "But,", you should also know that the Instruction Set Architecture documents were not released by Mr Bridgman, but were released by the AMD GPGPU guys, a team which was wholly separate from ATI in late 2007 already.

  5. #145
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    323

    Default

    Quote 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. 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.
    WTF? ARM is discouraging open source with Mali. Stop doing those drugs.

  6. #146
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    323

    Default

    People might want to read the original proposal written by Egbert, Emmes and myself, which started this whole open source strategy, and which pushed ATI to a point where they couldn't backtrack anymore.

    http://www.phoronix.com/scan.php?pag...nhd_four&num=6

    You might want to consider the bit:
    "AMD may additionally provide 3D shader optimization in an encapsulated module that can be dynamically loaded into libGL."

    We wanted fglrx to turn into a module with solid, opensource: modesetting/display, 2D support, Media support and basic 3d support. But Mr bridgman had other plans, and helped foster competing projects, and only released Docs as far as he was forced to by AMD (which died the second AMD ran out of money).

    Now, about the future: you will not get fglrx running on top of KMS. You will also not get it working with Mesa or other things. The kernel driver will, _at_ _most_, be moulded into a form where fglrx can make use of some shared in kernel memory management. I doubt command submission/CP will even be shared.

  7. #147
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    916

    Default

    Quote Originally Posted by libv View Post
    Now, about the future: you will not get fglrx running on top of KMS.
    You will also not get it working with Mesa or other things. The kernel driver will, _at_ _most_,
    be moulded into a form where fglrx can make use of some shared in kernel memory management.
    I doubt command submission/CP will even be shared.
    I expected to have exactly that shared...
    Why else would AMD share the drm kernel part?

    DISCLAIMER: I'm not an expert.

  8. #148
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,552

    Default

    Oh boy. When reading the article I thought "libv is going to see this eventually..." and so he did, as grumpy about it as ever

  9. #149
    Join Date
    May 2009
    Posts
    25

    Default

    Fortunately then, "common sense it not so common." Just as we have workstation customers that need the features and performance of the Catalyst driver, we need the open source stack to service others. Embedded customers use a huge variety of Linux variants and it's difficult to support them all using closed source. The open source drivers are not going away.
    Ok, I get that. But in recent years the open source driver got most features one way or the other.
    Can you people guarantee that the gallium driver will be treated as a first class citizen and still get all the features/docs or it will be used only as a fallback in cases catalyst can not be used?
    If people expect the community to take over the development (as suggested in a post) then this would be a huge step in the wrong direction in my opinion.

    If I miss something then I apologise

  10. #150
    Join Date
    Dec 2007
    Posts
    2,371

    Default

    Quote Originally Posted by iznogood View Post
    Ok, I get that. But in recent years the open source driver got most features one way or the other.
    Can you people guarantee that the gallium driver will be treated as a first class citizen and still get all the features/docs or it will be used only as a fallback in cases catalyst can not be used?
    If people expect the community to take over the development (as suggested in a post) then this would be a huge step in the wrong direction in my opinion.

    If I miss something then I apologise
    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.

Posting Permissions

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