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 dungeon View Post
    That is polemic about, developers and users does not think the same . You said "more open", but opensource users see "more blobs"
    No, there are fewer blobs. Catalyst has always been there, you just weren't thinking about it before

    blackiwid, remember why proprietary drivers exist in the first place -- they let vendors share big chunks of code across multiple OSes without leaking design info from those proprietary operating systems. That in turn lets vendors give you more features sooner without doubling or tripling the development costs.

    There is no mandate that proprietary drivers *have* to be better, it's just that they get somewhat of a free ride compared to Linux-specific driver development so it's probably more correct to say they get a head start as a consequence of code sharing.

    Leave a comment:


  • dungeon
    replied
    Originally posted by droste View Post
    Don't say "opensource users" when you actually mean "I"
    Ah well not only I, once when Debian package amdgpu driver and put it into right place, i will send you a link

    Leave a comment:


  • xeekei
    replied
    Originally posted by agd5f View Post
    More AMD developers working on the shared kernel driver.
    And AMD's whole Linux business relies on the kernel driver being uptodate and maintained. And since Linus won't allow stuff in the kernel that is only used by proprietary code, AMD will be forced to advance the open driver in pretty much the same pace as Catalyst. This is good.

    Leave a comment:


  • droste
    replied
    Originally posted by dungeon View Post
    That is polemic about, developers and users does not think the same . You said "more open", but opensource users see "more blobs"
    Don't say "opensource users" when you actually mean "I"

    Leave a comment:


  • agd5f
    replied
    Originally posted by entropy View Post
    Can you comment on what the expected advantages are for the open stack, having a shared kernel DRM driver?
    More AMD developers working on the shared kernel driver.

    Leave a comment:


  • entropy
    replied
    Can you comment on what the expected advantages are for the open stack, having a shared kernel DRM driver?

    Leave a comment:


  • agd5f
    replied
    Originally posted by blackiwid View Post
    so bridgeman, thx for some info, so there are coming some features to the free driver because of that unification, thats the "bribe" I talked/asked for.

    And why would it be bad if the free driver would support opengl 4.0 too? sounded like that no opensource driver user need that
    It will be great when the open source drivers support OpenGL 4.x, but it won't happen overnight. We have customers that need that functionality now and we have a driver tha supports it now, so it makes sense to enable that at least as an interim step.

    Originally posted by blackiwid View Post
    Another question would be, if the old chips/cards or the current are not using this new architecture, first is that really the case, I get that there will be a seperate blob with its old kernel part, but will there really be 2 different radeon drm modules for older cards and newer?

    And if thats really the case would it be really hard to backport some stuff from the new drm module to the old one?
    For old hardware, the existing open source and clsoed source drivers will continue to work. For new hardware, there will be a new kernel driver and the existing userspace drivers will work with the new kernel driver. E.g., the mesa radeonsi driver will support both new and old kernel drivers and the same is the case for the closed source user space drivers.

    Leave a comment:


  • dungeon
    replied
    Originally posted by dungeon View Post
    Yes i like that generally if it serve for opensource driver, i don't care if it serve for blobs .
    And more importantly what i think is that is true for the opossite - blob users also don't care about opensource one .

    Leave a comment:


  • dungeon
    replied
    Originally posted by bridgman View Post
    OK, I think this would make a lot more sense for you if you stopped calling it "unified opensource solution around blobs" since it is exactly the opposite
    That is polemic about, developers and users does not think the same . You said "more open", but opensource users see "more blobs"

    Yes, it means more developers working on the open source code, ie moving developer focus from closed source to open source for those components. Isn't that exactly what you wanted ?
    Yes i like that generally if it serve for opensource driver, i don't care if it serve for blobs . I understand for you (and company) both might be the same (only for different kind of users), but for me - nope .
    Last edited by dungeon; 13 October 2014, 12:46 PM.

    Leave a comment:


  • blackiwid
    replied
    so bridgeman, thx for some info, so there are coming some features to the free driver because of that unification, thats the "bribe" I talked/asked for.

    And why would it be bad if the free driver would support opengl 4.0 too? sounded like that no opensource driver user need that

    Another question would be, if the old chips/cards or the current are not using this new architecture, first is that really the case, I get that there will be a seperate blob with its old kernel part, but will there really be 2 different radeon drm modules for older cards and newer?

    And if thats really the case would it be really hard to backport some stuff from the new drm module to the old one?

    Leave a comment:

Working...
X