Announcement

Collapse
No announcement yet.

The Slides Announcing The New "AMDGPU" Kernel Driver

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

  • xeekei
    replied
    Originally posted by dungeon View Post
    Well i use radeon, maybe 11 years or something like that... if it not the best shape now it will never be . If you have userspace blob for Radeon cards, opensource will became only, more and more marginal
    The progression of the Radeon driver (very much thanks to AMD providing code and docs) contradicts your claim.

    Imagine this...

    AMD needs to implement multi-GPU support, and this needs code to be added to the amdgpu module.
    Since Linus Torvalds doesn't allow code into the kernel that can only be accessed/used by closed source code, they will effectively be forced to implement multi-GPU support in Radeon Mesa. Or at least lay the groundwork for it.

    In this scenario, the open driver benefits from the closed source driver sharing its kernel part.

    DISCLAIMER: I do NOT actually know whether or not multi-GPU support would require code being added to the kernel! This is just hypotheticals!
    Last edited by xeekei; 13 October 2014, 06:59 PM.

    Leave a comment:


  • dungeon
    replied
    Originally posted by xeekei View Post
    Radeon isn't good enough to satisfy every customer yet. If it were, it would've most likely taken over AMD's whole Linux/Unix market.
    Well i use radeon, maybe 11 years or something like that... if it is not in the best shape now it will never be . If you have userspace blob for Radeon cards, opensource will became only, more and more marginal

    Leave a comment:


  • xeekei
    replied
    Originally posted by dungeon View Post
    Drop non-pro plan, stay with opensource and improve that + add only sharable firepro blob for workstation users... basically i am fine with that .
    Radeon isn't good enough to satisfy every customer yet. If it were, it would've most likely taken over AMD's whole Linux/Unix market.

    Leave a comment:


  • dungeon
    replied
    Originally posted by bridgman View Post
    Who said we should shift resources from closed source to open source, preferably without going out of business in the process ? Raise your hands.

    Seriously, there are three ways to do it :

    1. Immediately drop Catalyst, walk away from the professional workstation market, lose money, spend less on drivers in the future.

    2. Stay with the status quo, keep improving the open source drivers while continuing to invest in Catalyst, see you in 2017.

    3. What you see here, or some mild variant.
    Drop non-pro plan, stay with opensource and improve that + add only sharable firepro blob for workstation users... basically i am fine with that .

    Leave a comment:


  • xeekei
    replied
    Originally posted by dungeon View Post
    Well it is just figurative question as example, so something from all that but design mostly, AFAIK this is first time in Linux history someone trying to unify blob+open driver needs in so complex thing like gpu driver with goal - "one driver, no out of tree parts, as far as we can" . I remember times when no one play games with opensource drivers, explain that now to typical radeon user . It is hard to distinguish what is typical opensource driver user now or who really needs blob... other then those FirePro users OK .

    Who are the kids who needs blob for Radeon cards and why? Raise your hands, are you happy because of this move? I am not
    All those smileys make you seem very passive-aggressive. I hate passive-aggression, it's dishonest.
    Also, this is a very good compromise. You as an exclusively FOSS driver user DO NOT lose anything with this move. In fact, you gain developer support to your driver of choice. What exactly is your issue? That the closed driver still exist even though it's smaller?

    The closed parts are shared between Windows and Linux, so theoretically they can piggy-back on the resources of the Windows driver team.
    I also hope we'll see Wayland support, Mantle on Linux (and making it an open standard too), FreeSync etc.

    YOU HAVE NOT LOST ANYTHING!

    Leave a comment:


  • Nille_kungen
    replied
    Originally posted by bridgman View Post
    Hands up all the people who said we should shift resources from closed source to open source, preferably without going out of business in the process.

    This is what it looks like.
    \o/ AMD is doing a good job with there Linux support.

    Leave a comment:


  • CTown
    replied
    Originally posted by bridgman View Post
    Initial implementation will be for newer hardware only (basically anything not already supported by radeon). Apart from only wanting one kernel driver upstream for each HW device, there are some architectural changes going into the new code to let us work more effectively with the HW teams going forward (basically organizing the code around individual HW block versions rather than entire chips).

    The overall idea was driven initially from the open source side, so there was no "convincing" required. The plan doesn't work without a good open source userspace.
    Seems like things will be much more organized in the future. Thanks for the response.

    Leave a comment:


  • bridgman
    replied
    Who said we should shift resources from closed source to open source, preferably without going out of business in the process ? Raise your hands.

    Seriously, there are three ways to do it :

    1. Immediately drop Catalyst, walk away from the professional workstation market, lose money, spend less on drivers in the future.

    2. Stay with the status quo, keep improving the open source drivers while continuing to invest in Catalyst, see you in 2017.

    3. What you see here, or some mild variant.
    Last edited by bridgman; 13 October 2014, 06:29 PM.

    Leave a comment:


  • dungeon
    replied
    Originally posted by bridgman View Post
    Are you asking about the case where a performance optimization in the kernel helps the closed source UMD more than the open source UMD because of lower overhead in the closed source UMD ? In that case there isn't really a choice.

    You seem to be asking about a case where there's a design tradeoff between open and closed source drivers, but since the user-kernel interface will be the same I don't see that coming up very often. If you're talking about defaults or tuning values for heuristics I imagine we would just make them configurable and configure differently depending on which stack was installed.

    Even there the differences tend to be more a function of usage scenarios than driver stacks, eg some workstation users want a single app to be able to consume all the resources in the system for optimal performance and see that as a Must Have, while for most systems that is considered a Bad Thing since it can cause problems for other apps.
    Well it is just figurative question as example, so something from all that but design mostly, AFAIK this is first time in Linux history someone trying to unify blob+open driver needs in so complex thing like gpu driver with goal - "one driver, no out of tree parts, as far as we can" . I remember times when no one play games with opensource drivers, explain that now to typical radeon user . It is hard to distinguish what is typical opensource driver user now or who really needs blob... other then those FirePro users OK .

    Who are the kids who needs blob for Radeon cards and why? Raise your hands, are you happy because of this move? I am not
    Last edited by dungeon; 13 October 2014, 06:20 PM.

    Leave a comment:


  • agd5f
    replied
    Everyone seems to keep asking the same question, but ignoring my response. Let's try this again: Having a shared components benefits both drivers since there will be more developers working on those components. We will now have a number of formerly closed source developers working on new open source components in additional to the open source developers. It doesn't matter what userspace graphics stack is running when you light up the displays or set up the power management hardware. Having more developers to help write and maintain and debug that code helps everyone.

    Leave a comment:

Working...
X