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

[F i L]

Sure, AMD has customers who "need Catalyst" (Really? Says who? The same clueless people at AMD who thought that the FOSS driver had already reached OpenGL 4.3?), but those can equally well be considered "legacy driver" customers soon enough.

I need Catalyst for Blender (sculpting), especially on my 7850 (and yes, I know I should have bought Nvidia). It's been a year or so since I've tried the open-source drivers really, but last I tried Blender got 3-6x the framerate with Catalyst over the FOSS drivers on my old 4870. Until that gap is closed, I'll be using Catalyst, regardless of how great the FOSS 2D stuff is, or how many odd bugs fglrx has.

[entropy]

Someone over at /. came up with a post by Matthew Garret from mid 2012:

http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/000336.html

Back then he suggested to NVidia to do exactly what AMD seems to try now.

[entropy]

You are wrong. They Talk about the API/ABI to the Userspace and they is stable.

I know that the userspace API is very stable.
However, I didn't actually get Marc's point,
so this link should always work...

[Damian_Ivanov]

@bridgman:

For the record (maybe AMD wants to know such stuff). The last PC I bought was last September. I did base my decision intel-nvidia/amd on Linux engagement and how it functions on Linux. i now have a new Radeon GPU and a Bulldozer CPU (FX8320).

PS: Both really rock and I am especially excited about the CPU. In some benchmarks you find online, it says it has less performance than an I7. This is true for some workloads (single threaded apps). On Windows 7 and 8 I7 outperforms the FX series. On Linux FX outperforms the I7.
and btw. single threaded apps - you have only one process running, you have a lot in the background, think about that!

[chrisb]

You are wrong. They Talk about the API/ABI to the Userspace and they is stable.

No, you are wrong. The original poster was talking about having a stable driver API in the Linux kernel, which is why the link to the Linux kernel "stable api nonsense" was appropriate.

[chrisb]

- The blob would not violate all kinds of licenses and be illegal to distribute for distributions, unlike Nvidia's legal minefield.

Actually, there are some developers who argue that user-space binaries that rely on custom functionality from kernel modules are illegal. The text of the kernel GPL license only states that programs that use the normal system calls are not derivative works:

The COPYING file shipped with the kernel begins with this text:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".
Normally, kernel developers see user space as a different world with its own rules; it is not at all common for kernel maintainers to insist on free licensing for user-space components. Dave's raising of licensing issues might also seem, on its face, to run counter to the above text: he is saying explicitly that closed user-space graphics drivers might be a work derived from the kernel and, thus, a violation of the GPL. These claims merit some attention.

The key text above is "normal system calls." A user-space graphics driver does not communicate with its kernel counterpart with normal system calls; it will use, instead, a set of complex operations which exist only to support that particular chipset. The kernel ABI for graphics drivers is not a narrow or general-purpose interface. The two sides are tightly coupled, a fact which has made the definition of the interface between them into a difficult task - and the maintenance of it almost as hard. While a program using POSIX system calls is clearly not derived from the kernel, the situation with a user-space graphics driver is not nearly so clear.

and

We are going to start to see a number of companies in the embedded space submitting 3D drivers for mobile devices to the kernel. I'd like to clarify my position once so they don't all come asking the same questions.

If you aren't going to create an open userspace driver (either MIT or LGPL) then don't waste time submitting a kernel driver to me.

This issue of whether it is legal to distribute a user-space driver that uses a kernel shim to provide custom "not normal" system calls hasn't gone to court yet, so we don't have a definite legal answer. Given that the Linux kernel has thousands of copyright holders, I wouldn't be surprised if an IP lawyer convinces one of them to test the legal field with this question at some point in the future.

What AMD might do is to convert the existing open source driver to serve the dual purpose of providing system calls for both the open and closed user-space drivers. The question then is whether this is achievable without requiring custom system calls for the closed source driver. On the face of it, it might seem questionable - if they could have implemented the closed source user-space driver using only the existing kernel functionality in the first place, then why would they have bothered to write the closed kernel driver? But perhaps they had other reasons e.g. "protecting IP". Either way, Linus is unlikely to accept any patches that are aimed solely at providing functionality for a closed source user-space driver.

[lano1106]

this is very interesting and I applaud AMD idea.

My main worry is how many Linux developers would be working on this?

I'm asking because with the pace of development of catalyst (about 3 bug fixes per month) it seems like the poor guy is alone and fix rougly less than 1 bug per week. If the idea discussed in this article requires major refactoring, that will take a very long time before seeing something.

Concerning the explanations behind decision to have catalyst closed source:

1. It contains over a million lines of code and it is too big hence it would not attract contributors anyway.

I believe that it is not required to understand everything to a huge software project to be able to contribute to it. How many lines of code does the kernel have and does it stop it to get many new contributors to it?

With good methods and tools, it is very easy to narrow down to very precise function where a problem is. Without the source I have been able to pinpoint problems 3-4 times inside catalyst. ie: XvPutImage for xserver v.15 support in 14.2. With the code source, I could have fixed the problem myself without having to wait for the sole AMD driver dev to fix and release the fix.

2. Keep the sauce secret.

It is AMD right and as a customer, I do not really care about using closed source software but only at one condition: The closed source software has to be top quality and bugs needs to be addressed quickly.

If AMD is not able to provide that, they should let their customers do it themselves. I have installed 14.3 yesterday and here are the issues that I still have:

opencl is not able to detect more than 1 cl device: The only reason that I had to stick with catalyst was good opencl 1.2 support. This one is gone now!
I have a deadlock in fgrlx making X unkillable and using 100% CPU while playing a steam game. I have to reboot my machine and it did happen twice yesterday.
This one is fixed in 14.3 but it was so bad that I need to mention: Impossible to play video without crashing X on the first frame displayed.

As a professional software developer myself, this is too much problems for me. As I deal already fulltime with software problems, when I am at home, I just want a system that works well. Hence, still waiting a couple of months to see the situation improve is too much to ask. I'll keep my 7970s, install open source drivers, keep watching if AMD finally delivers but for my main machine, it will now be a high-end NVIDIA card to make my life easier.

Sincere good luck with your ambitious project!

[Vim_User]

I am not quite sure how they would do this:
- Mantle on Linux? Sorry, resources are scarce, maybe we can later look at if it is even worth our time.
- UVD for RS780/880/RV790? Sorry, resources are scarce, maybe later, maybe never.
But:
- Major changes in the driver to be able to use the radeon kernel module, which will take a significant amount of developer time? Hey, we totally can do that!

WTF?

[Anarchy]

Can somebody tell me how win, mac, and android are handling the situation with the closed source drivers and why is it such a pain in the ass to do the same thing for desktop Linux? Is it because of the outright hostile behavior of the kernel devs towards anything and everything closed source, or is it simply an engineering problem to which nvidia dedicates more engineering effort and amd very little?

[smitty3268]

I am not quite sure how they would do this:
- Mantle on Linux? Sorry, resources are scarce, maybe we can later look at if it is even worth our time.
- UVD for RS780/880/RV790? Sorry, resources are scarce, maybe later, maybe never.
But:
- Major changes in the driver to be able to use the radeon kernel module, which will take a significant amount of developer time? Hey, we totally can do that!

WTF?

Well, the whole point here is that once done it would reduce the time they have to spend on their driver, since support would just already work in the kernel. So the idea is to do some work up front to save down the road.