Page 14 of 16 FirstFirst ... 41213141516 LastLast
Results 131 to 140 of 159

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

  1. #131
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,332

    Default

    Quote Originally Posted by smitty3268 View Post
    It's completely ridiculous that such a thing would take more than 30 seconds for someone to write, just by going through the svn log, or whatever system they use.

    On the other hand, i also think it's pretty silly to need one. The only people it would really help would be michael, so he could just copy/paste it into an article every month. For most users, you just try out fglrx and see if if works for you or not, and if you have something in particular you are wondering about you just try the new version or get on here and ask people if it's been fixed. Adding a change log to each driver release isn't going to change that.
    Indeed. It doesn't take a highly educated developer to write a changelog with NDA entries removed. A minimum wage part-time secretary will do if a dev really can't spare a minute.

  2. #132
    Join Date
    Sep 2007
    Posts
    365

    Default

    This sounds, as if it would make port of fglrx to *BSD a lot easier, considering most of them now have a port of the radeon module in their trees.

  3. #133
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,665

    Default

    Quote Originally Posted by tuubi View Post
    Ah, didn't realize you consider installing and using a dedicated compositor an "option" you can just set, and that might be required depending on your window manager. Never mind then, just trying to be helpful.
    I'm using KDE, so it is an option. But yea, I tried everything: all the settings in the NVIDIA settings, different xorg.conf settings related to VSync, different xrandr settings, different compositor settings. Nothing makes any difference. The NVIDIA devs themselves say that things like that happen due to something interacting improperly with something else, but the hardware is so complex that it could be anything and anywhere...

  4. #134
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    936

    Default

    @@twriter, @Bridgman, @agd5f

    Can you share something about the "planned" transition process?
    Will we probably see some beta Catalyst using this new approach alongside
    with the current Catalyst architecture, or do you expect it to be replaced from
    one Catalyst release to the next.

    I'm aware this is very early to tell definitely (and even might become reality at all),
    but most probably this has been discussed already.
    Last edited by entropy; 03-24-2014 at 08:26 AM.

  5. #135
    Join Date
    Oct 2007
    Posts
    124

    Default AMD Thanks and congratulations

    I do have both ATi and NVIDIA - SLI - old cards, and none of them work with Mutter, i do prefer XFCE, but is a shame Mutter/muffin still odes not work well

    Intel driver is open source
    ATI is going to be high % open source + additional non blob privative software

    What about NVIDIA, the famous FINGER, their blob vs open source BIG GAP
    Why does people prefer it at Linux?

    Great blob, but it can change. If i were NVIDIA, I would start to copy the ATI strategy, open source + non blob software

    Game developers will be able to improve open source drivers, students learn, and even the small closed non blob parts can be improved "for free" from game programmers with NDAs as Steam improved a lot Nvidia blobs

  6. #136
    Join Date
    Jun 2008
    Posts
    17

    Default

    This article made me eye that R9 270x ... nah j/k I was planning to get it anyway!

  7. #137
    Join Date
    Feb 2011
    Location
    Toronto, ON, Canada
    Posts
    31

    Default

    Thanks, you summarized it well.

    Quote Originally Posted by smitty3268 View Post
    No change to Mesa was discussed here, so the same things that are going on now will continue to go on, just as they have been.
    Exactly! We are not reducing our efforts on the open source stack. There will be more collaboration between the teams which will benefit both stacks.

  8. #138
    Join Date
    Feb 2011
    Location
    Toronto, ON, Canada
    Posts
    31

    Default

    Quote Originally Posted by entropy View Post
    @@twriter, @Bridgman, @agd5f
    Can you share something about the "planned" transition process?
    Sorry, as you speculated, it's too early to share those details.

  9. #139
    Join Date
    May 2009
    Posts
    30

    Default

    Quote Originally Posted by smitty3268 View Post
    Come on, read the article and use some common sense.


    Nothing. No change to Mesa was discussed here, so the same things that are going on now will continue to go on, just as they have been.


    They already are, through their OSS team. There was no change to that being discussed anywhere, so there would still be a separate OSS team working on Mesa, and closed source team working on fglrx userspace. They'd just share the same kernel driver.


    For desktop users, yes. For AMD's commercial clients, no. At least not yet.


    According to the article - which you should have read - there are not. They are all in the userspace code.


    Exactly because of that. It's only now that the radeon kernel driver is in good enough shape that they can consider using it. Perhaps in the future the userspace side of the driver will become good enough they can use that, too, and just drop fglrx entirely on linux, but it isn't there yet like the kernel portion is.


    No, and such a thing was never mentioned, or even slightly hinted at anywhere at all. I have no idea where you are getting such ideas from.
    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
    Last edited by iznogood; 03-25-2014 at 04:06 AM.

  10. #140
    Join Date
    Sep 2007
    Posts
    365

    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 ?
    If the OSS radeon driver (not the kernel part) would die, then fglrx would be the only user of the radeon kernel part. Thus, the radeon driver would have to be removed, as the open driver parts for binary blobs are not allowed in the kernel.

Posting Permissions

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