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

[curaga]

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.

[oleid]

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.

[GreatEmerald]

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...

[entropy]

@@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.

[mitcoes]

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

[ningo]

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

[twriter]

Thanks, you summarized it well.

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.

[twriter]

@@twriter, @Bridgman, @agd5f
Can you share something about the "planned" transition process?

Sorry, as you speculated, it's too early to share those details.

[iznogood]

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

[oleid]

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.