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

[AnonymousCoward]

It's been a year or so since I've tried the open-source drivers really

There's your problem; expect massive performance increases between then and now with the FOSS driver, especially with RadeonSI (which is used with your card).

[smitty3268]

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?

You seem to be mixing a lot of different stuff up here, but i'll try to clarify a bit.

1. Win and Mac are proprietary, which means that proprietary code can link into it with no problems. You could do the same with BSD code. You cannot with GPL, because it then becomes a "derived" code which is covered by the GPL as well, and the gpu driver developers don't want that. So to work around this, they create a little open source shim code which talks to the internal kernel API's and their proprietary driver, and claim that works around the whole issue.

Some people have doubts about that, but no one really cares enough to sue, because most people want the drivers to stick around anyway.

Just to be clear, this issue has nothing to do with the devs being "hostile" or "friendly". It's 100% about the legal requirements of the GPL and lawyers. Even if the devs said to go ahead and ignore the law, the lawyers at the GPU companies would ignore them because they don't want to be exposed to million dollar lawsuits from random people on the internet who download a linux distro and decide to sue them.

2. Nvidia does spend more money on their linux drivers, there is no question about that. But they have the same issues. When new kernels come out, your nvidia driver won't work until they come out with a new version that's updated to work with it.

3. The problem is compounded by the fact that the linux internal API isn't frozen, new versions are constantly coming out, and different distros all have their own patchsets. In Windows and Mac, that API can sometimes change, but it mostly stays the same over long periods of time and they have much fewer versions of the OS to support. In linux, every release usually breaks something. To help mitigate that, the open source shim the proprietary drivers ship with doesn't come pre-built. It's instead compiled and linked against your kernel when you install the driver, so that it can work with your specific version.

4. The idea here is that AMD would get rid of their kernel side code entirely, and just use the same kernel API that the OSS drivers use. That would mean they could probably get rid of the shim as well, since they'd be using standard kernel api's rather than manually hooking in their own code. And it should just work by default in all the kernels out of the box, since it would be maintained as part of that kernel rather than being part of the AMD driver.

5. Android is a completely separate beast. Most ARM devices just have completely custom drivers built directly for them - which is one of the reason official updates are so slow. There isn't generally a generic driver that they use, instead the manufacturer writes the driver specifically for each piece of hardware. Then any updates you get are carefully controlled - sent to you via the phone company, for example - and not just downloaded at will off the internet.

[GreatEmerald]

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.

That's the whole idea, to use the radeon kernel driver instead of the catalyst one. It's not a shim and is actually needed for radeon.
As for why they bothered to write the closed kernel driver: I'm pretty sure that at that point, the radeon kernel driver did not exist.

[curaga]

Michael didn't mention it by name, but HDCP would be another thing that would not be supported. It would need to be in kernel, but doing so would obviously reveal things, or require a blob extension that cannot have its interfaces upstreamed.

[Nille]

what kernel developers think about this?

[V10lator]

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?

Because there was no (good) open-source kernel driver available when fglrx was born. Today the open-source kernel driver is almost as advanced as the closed-source one.

Either way, Linus is unlikely to accept any patches that are aimed solely at providing functionality for a closed source user-space driver.

When they have to add missing functionality to the open-source kernel driver they could always add that stuff to the gallium driver, too, so it would be a win-win.

[GreatEmerald]

Michael didn't mention it by name, but HDCP would be another thing that would not be supported. It would need to be in kernel, but doing so would obviously reveal things, or require a blob extension that cannot have its interfaces upstreamed.

That's what I was talking about. Who cares about graphics card HDCP, when there are no players capable of HDCP?

[a user]

What about Intel? AFAIK Intel graphics driver is totally open. Does Intel has any disadvantages right now because of this?

yes they have: both nvidia and amd are violating some patents in their secret souce that they do not want to be seen. and intel has to skip some nice stuff patented by others because they are all open source.

p.s. just my guess, but i would bet a lot of money on this.

[dee.]

Michael didn't mention it by name, but HDCP would be another thing that would not be supported.

HDCP is evil. The less support there is for such atrocities, the better.

[Vim_User]

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.

I don't get that. They still would have to collaborate with the radeon developers to get release-day support for new hardware, tehey still have to get all the features work that aren't currently supported with radeon, so where exactly would they reduce the time? This sounds like: Hey, we offload all this work to the FOSS developers which will reduce the work we have to do and as a nice side effect they can't blame us when new hardware doesn't work, we just say "Here is the documentation, why don't you just implement it?"
Sorry, but AMD has a nice track record of screwing their customers and to me this sounds awfully like another attempt.