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

[Vim_User]

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

They already have working drivers, so if your prediction would be true they already would have stopped development of one of them two save money. Would be much easier, since they would also save the development time that is necessary for the transition.
Besides that, how could they stop development of the free driver? Even if they fire the open source developers I bet the driver would be continued by volunteers, in the same way the nouveau team works.

[twriter]

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.

Fortunately then, "common sense it not so common." Just as we have workstation customers that need the features and performance of the Catalyst driver, we need the open source stack to service others. Embedded customers use a huge variety of Linux variants and it's difficult to support them all using closed source. The open source drivers are not going away.

[spstarr]

This might fix even older AMD GPUs

With a common DRM driver, GPU resets for us older R600 cards might be fixed if fglrx's kernel bits fold into the radeon DRM driver this is something I hope can happen. I can't just replace my laptop GPU you know, stability has been a big issue for me on my RV635 and perhaps fglrx's kernel has some errata/workarounds.

I wonder, shouldn't AMD let the FLOSS AMD employees see fglrx's kernel driver directly instead of keeping the teams separate? Or they do?

Shawn

[libv]

Great article, Michael!

This comes totally unexpected, indeed.

Besides the risks, this sounds exciting! I just love people and companies
that are brave enough to rethink their previously made decisions.
AMD were among the first to release detailed (and useful) programming
docs for GPUs and this might be another groundbreaking thing.

You do know that this documentation thing was as the SuSE guys (egbert and I) proposed to AMD, right?
You also do know that Mr Bridgman did not release all the documentation he handed us, contrary to our agreement?
You also do know that documentation stopped in february 2008, when AMD ran out of money and the work with SuSE discontinued? (only recently did some documentation seep out again).
And before you say "But,", you should also know that the Instruction Set Architecture documents were not released by Mr Bridgman, but were released by the AMD GPGPU guys, a team which was wholly separate from ATI in late 2007 already.

[libv]

Sounds promising, but it must be mentioned that the #1 reason that graphics on Linux is a mess (especially on the ARM side of things) is because though the engineers would be more than happy to open-source (or at least open up) their drivers, but the suits above them are absolutely scared that doing so would reveal the secret sauce of their GPUs. Still, attitudes do vary - ARM is trying to encourage partners to open up and has been leading by example with Mali. At the other end of the scale, you have Imagination where practically everything is a black box. They're starting to improve now, for Rogue we now have actual block diagrams and what each USC actually has, but there's still a long way to go.

WTF? ARM is discouraging open source with Mali. Stop doing those drugs.

[libv]

People might want to read the original proposal written by Egbert, Emmes and myself, which started this whole open source strategy, and which pushed ATI to a point where they couldn't backtrack anymore.

http://www.phoronix.com/scan.php?page=article&item=amd_radeonhd_four&num=6

You might want to consider the bit:
"AMD may additionally provide 3D shader optimization in an encapsulated module that can be dynamically loaded into libGL."

We wanted fglrx to turn into a module with solid, opensource: modesetting/display, 2D support, Media support and basic 3d support. But Mr bridgman had other plans, and helped foster competing projects, and only released Docs as far as he was forced to by AMD (which died the second AMD ran out of money).

Now, about the future: you will not get fglrx running on top of KMS. You will also not get it working with Mesa or other things. The kernel driver will, _at_ _most_, be moulded into a form where fglrx can make use of some shared in kernel memory management. I doubt command submission/CP will even be shared.

[entropy]

Now, about the future: you will not get fglrx running on top of KMS.
You will also not get it working with Mesa or other things. The kernel driver will, _at_ _most_,
be moulded into a form where fglrx can make use of some shared in kernel memory management.
I doubt command submission/CP will even be shared.

I expected to have exactly that shared...
Why else would AMD share the drm kernel part?

DISCLAIMER: I'm not an expert.

[GreatEmerald]

Oh boy. When reading the article I thought "libv is going to see this eventually..." and so he did, as grumpy about it as ever

[iznogood]

Fortunately then, "common sense it not so common." Just as we have workstation customers that need the features and performance of the Catalyst driver, we need the open source stack to service others. Embedded customers use a huge variety of Linux variants and it's difficult to support them all using closed source. The open source drivers are not going away.

Ok, I get that. But in recent years the open source driver got most features one way or the other.
Can you people guarantee that the gallium driver will be treated as a first class citizen and still get all the features/docs or it will be used only as a fallback in cases catalyst can not be used?
If people expect the community to take over the development (as suggested in a post) then this would be a huge step in the wrong direction in my opinion.

If I miss something then I apologise

[agd5f]

Ok, I get that. But in recent years the open source driver got most features one way or the other.
Can you people guarantee that the gallium driver will be treated as a first class citizen and still get all the features/docs or it will be used only as a fallback in cases catalyst can not be used?
If people expect the community to take over the development (as suggested in a post) then this would be a huge step in the wrong direction in my opinion.

If I miss something then I apologise

As stated on many occasions previously in this thread, the open source user-mode gallium drivers are not going anywhere and will continue to be developed by AMD in the same manner as they are today. We have customers where open source is a requirement and we have customers where the workstation features of catalyst are a requirement.