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

[nightmarex]

This sounds absolutely brilliant and it would be genius if they can pull it off.

- Open drivers would profit from more people working on the kernel and the resulting optimisations, as well as early support for new hardware.
- AMD cards would work out of the box with open drivers, and provide a great default experience for all of us who prefer
- Those who want more woompfh for their CAD, professional workstation stuff and Workraft can download the userspace blob easily.
- The blob would not violate all kinds of licenses and be illegal to distribute for distributions, unlike Nvidia's legal minefield.
- The blob could happily use kernel interfaces for seamless integration with intel IGPs, unlike Nvidia.

Everybody wins!

I agree i guess. I just want fast stable AMD performance and if this means that a soft radeon reset is possible (like in modern Windows) that's amazing progressive. I will be buying more AMD to show my support. Thanks guys, Thanks bridgman for your helpful comments. Thanks God for making AMD see the light-ish!

[GreatEmerald]

Patents are a really expensive way of protecting IP, and don't work particularly well in a closed source environment since you have no obvious way to know if a violation occurred. You also have to make the information public as part of the patent process, and in many cases the idea is more useful than the patentable details (since patents really describe a specific implementation rather than an underlying idea).

Patents work well when the IP is visible to the general public by virtue of how it is used in a product, but in a closed-source environment using trade secrets requires less effort, less expense, and is generally more effective... and yes that does make closed source software a bit of a self-perpetuating thing.

Someone asked earlier about making everything open source except a few small binary modules containing the secrets. Problem is that reverse engineering small binary modules surrounded by open source is really easy. The idea has been tried a few times already (IIRC Intel used to have a binary shader compiler module, for example) but never seemed to work for anyone.

Well that's the thing, why is patenting things and then opening the source not possible? It's more effort in the short run, but sounds like less effort in the long run.

About reverse engineering, that doesn't sound like that strong an argument to me... I'm not really sure who would want to reverse-engineer such things. NVIDIA probably wouldn't be interested in those optimisations to begin with, and the radeon team probably has more interesting things to do with their time (or come up with even better optimisation ideas). And you can reverse-engineer such things from blobs as well, with enough determination. The benefits of such things sound like they outweigh the disadvantages... Though I haven't heard anything about the intel binary shader compiler or anything else similar.

[smitty3268]

Huh, i did NOT see this coming

It's an interesting idea. I think a lot of the things michael brings up are fairly easily worked around, but the 1 thing i would be concerned about would be the timing of new hardware support, and how new hardware would work with older distros.

I know the oss driver has finally caught up with new hardware, but it still remains to be seen whether the next round of new hardware will be supported in mainstream distros by the time it is actually released rather than requiring you to go compile git kernels and so on. It would be important to at least get to the point that Intel is at right now, and even then you are at a worse place than the current fglrx support gives you if you want to go back and run a LTS distro.

As a couple other people have mentioned, it would be amazing to be able to run the gallium drivers on your system and then dynamically switch to fglrx for those 1 or 2 apps that need the highest performance or GL version that is still missing on the oss side. Fglrx has always sucked at running the basic desktop, and they could start ignoring that completely, and their workstation customers could just start using fglrx on their workstation apps only where it is actually optimized. Same for running games on SteamOS - you could run the system with the gallium drivers and switch into fglrx as needed for games.

[asdfblah]

What about OpenCL? Couldn't AMD have just left it closed source, as some sort of "plug-in" instead of developing it from scratch? I mean, it's great to have it open-sourced, but I'm not sure many people using it cares about it being FOSS... more likely, they just want it working fast and well. Also, isn't LLVM kind of a mess? AMD could just have distributed a static version of it, no?
Oh, and what about HSA, as someone said before? When will devs finally be able use the GPU as another powerful device along with the other devices in their applications?

[smitty3268]

About reverse engineering, that doesn't sound like that strong an argument to me... I'm not really sure who would want to reverse-engineer such things.

AMD and NVidia both have people dedicated to reverse engineering the others product and making sure they aren't falling behind.

[jrdls]

Still, attitudes do vary - ARM is trying to encourage partners to open up and has been leading by example with Mali.

This is off-topic but... could you clarify? As far as I know they haven't opened up the way intel and amd have.

[bridgman]

Well that's the thing, why is patenting things and then opening the source not possible? It's more effort in the short run, but sounds like less effort in the long run.

It's not opening *your* source that lets you detect patent violations, it's opening the *other* guy's source, and we don't control that

About reverse engineering, that doesn't sound like that strong an argument to me... I'm not really sure who would want to reverse-engineer such things. NVIDIA probably wouldn't be interested in those optimisations to begin with, and the radeon team probably has more interesting things to do with their time (or come up with even better optimisation ideas). And you can reverse-engineer such things from blobs as well, with enough determination. The benefits of such things sound like they outweigh the disadvantages... Though I haven't heard anything about the intel binary shader compiler or anything else similar.

It's a *lot* easier to reverse engineer a small binary bundle of secrets in the middle of an open source stack than it is to reverse engineer 100MB of binary drivers.

IIRC the Intel binary shader compiler module had already been abandoned by the time we re-started open source gfx driver work in 2007.

[Prescience500]

No, as long as application developers don't implement the graphics features like in the spec., AMD needs to have workarounds for that programs insider der prop. driver, to not loose customer which use that programs. Given that the joke with nv dont get that many errors because they don't implement the spec that strict like amd does, but that my not apply to de oss driver.

That may not always be a problem. Imagine what would happen if one day a really major player...say Valve...announced that they would only install the open AMD drivers after a certain date and that if game developers wanted their games to be performant, they would have to either follow the spec or provide the hacks in the game's code rather than in the driver.

This may not be very likely, but I can dream, can't I?

[blackout23]

So if they pull this of catalyst might actually move back into the Arch Linux official repos. It was kicked out since it was to much of a PITA to maintain in a rolling release distro.

[omglotsofdots]

Well done

Good exclusive. Very promising news.