Announcement

Collapse
No announcement yet.

The Slides Announcing The New "AMDGPU" Kernel Driver

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

  • bridgman
    replied
    Originally posted by blackiwid View Post
    Again what next could happen would be taht nvidia tells that they send patches taht vesa can use some minor features for their new kernel-backend, but also their blob use it much more, then the vesa driver could use 2-3 minor features of it, and their blob use all features of this new thing.
    If we were doing that then I think the maintainers would legitimately push back hard (ie kick us to the curb).

    Leave a comment:


  • blackiwid
    replied
    Originally posted by bridgman View Post
    It's not a proprietary driver in the kernel. Open source kernel, open source userspace, with optional proprietary userspace on the same UKI.
    yes but we dont allow nvidia to do such thing, release the kernel parts opensource, include it in to the kernel and let some proprietary X driver use it or something like that. Again what next could happen would be taht nvidia tells that they send patches taht vesa can use some minor features for their new kernel-backend, but also their blob use it much more, then the vesa driver could use 2-3 minor features of it, and their blob use all features of this new thing.

    Maybe I am wrong but this kernel part can then even use the GPL_ONLY marked functions, so the blob can use through this Proxy stuff that non-gpl software should not be able to use.

    I am just asking, maybe I am wrong and all is wonderful, but am I really the only one that sees here a problem?

    Leave a comment:


  • profoundWHALE
    replied
    What I'd like to know is if this new strategy will make AMD drivers in general more portable across different operating systems, from Mac, to Windows, to Android, to Linux, to the BSDs, etc. I assume it'll at least make the drivers a lot more stable, period.

    Leave a comment:


  • bridgman
    replied
    Originally posted by blackiwid View Post
    hmm sad that u ignored my post #70 (page 7).

    I think thats a important point, I was pro doing this at the beginning, but I am not shure anymore, I am kind of a amd fanboy but still we should not allow amd stuff others are not allowed. At least not with some good reasons. Till now I only see a vague promise that they will do more opensource stuff in the future.

    There should be a zero tollerance for propriatary drivers in the kernel, at least thats my current oppinion. At least we should get bribed if we (the kernel devs) allow a company something other companies are not allowed. Would like to hear other opinions onto that topic.
    It's not a proprietary driver in the kernel. Open source kernel, open source userspace, with optional proprietary userspace on the same UKI.

    Leave a comment:


  • dungeon
    replied
    Originally posted by nanonyme View Post
    Could you provide a source for this information, please?
    Of course there is no source, just asumpation based on time were droping happened in years 2006>2009>2012>??? so what is next year?

    http://www.phoronix.com/forums/showt...382#post445382

    Leave a comment:


  • blackiwid
    replied
    hmm sad that u ignored my post #70 (page 7).

    I think thats a important point, I was pro doing this at the beginning, but I am not shure anymore, I am kind of a amd fanboy but still we should not allow amd stuff others are not allowed. At least not with some good reasons. Till now I only see a vague promise that they will do more opensource stuff in the future.

    There should be a zero tollerance for propriatary drivers in the kernel, at least thats my current oppinion. At least we should get bribed if we (the kernel devs) allow a company something other companies are not allowed. Would like to hear other opinions onto that topic.

    Leave a comment:


  • drSeehas
    replied
    Originally posted by Kano View Post
    ... an extra driver for new cards only ... When a New xserver/kernel is out expect fglrx broken ... not even the officially released 14.9 driver has xserver 1.16 support ... As long as there are cards that need it you have MORE work than before and not less!
    Right, but not if you soon drop support for these "old" cards ;-)
    ATI/AMD did it already for all cards for the BSDs.

    Leave a comment:


  • Nobu
    replied
    Originally posted by LEW21 View Post
    inb4 steam shipping catalyst.so in its basic runtime, so the Steam games will always use the same AMD driver.
    That would be a horrible idea, even if it were possible (I don't believe it is, at least until Wayland is the primary rendering api). Catalyst, especially, is picky about the version of the Linux kernel it's run on (not to mention Xorg, and other bits). Even if that were not the case, there are different versions of Catalyst, which support different generations of hardware (if I select hd7xxx on AMD's driver page, I get Catalyst 14.1, but if I select mobile hd4xxx I get 13.1). I think it's just a bad idea, and user/vendor (depending on who installed the OS) knows best in this case.

    Leave a comment:


  • LEW21
    replied
    inb4 steam shipping catalyst.so in its basic runtime, so the Steam games will always use the same AMD driver.

    And I think that's OK - if the game is already closed source, you don't really gain anything from using open userspace driver.

    Leave a comment:


  • nanonyme
    replied
    Originally posted by dungeon View Post
    Yep, shit it is but they will probably drop fglrx support for some (if not all ) chips next year . Lets hope it will be better when they stay only with this unified amdgpu driver
    Could you provide a source for this information, please?

    Leave a comment:

Working...
X