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

[Herem]

There are lots of workstation customers that need high performance OpenGL 4.x and OpenCL 1.x support right now. While it would be nice to focus on a solely open source user mode drivers, it's not really feasible in the short term.

Does this mean AMD plan a migration from Catalyst in the medium to long term if and when the FOSS drivers reach feature compatibility?

[FourDMusic]

Personally, I think that most of Michael's concerns are not as problematic as it sounds like, and that this approach is very much doable

Agreed. The solution they are discussing is not something that is going to drop next week. Additionally, they have already stated that they have a semi-working prototype. While there may be a LOT of pieces to put together, none of Michael's issues stood out to me as a huge issue. Just to hit a few:
1) Significant code re-factoring: that would be expected. Devs refactor every day. This may be on a larger scale than usual, but not a blocker.
2) new user-space interfaces: this just goes along with the significant refactoring since they would need to use the DRM interfaces instead of the catalyst kernel driver interfaces. You could view this as simply a part of refactoring.
3) features currently missing from linux driver: sweet - so when they port it over, open source driver gets the new features for free
4) It's not clear how AMD would handle patent-encumbered or legally risky code: you then go on a few paragraphs later saying that there isn't too much in the kernel side of the catalyst driver. It's all in the user-space side, which won't be open.
5) new IOCTL interfaces for just the Catalyst driver: Linux might have a problem with this. The solution is simply to have interfaces that both the closed AND open source driver can use. This seems like a win to me.
6) clear legal/technical review: they already need to do this when dropping new features in the open source driver

It would be awesome if this really comes to fruition. Correct me if I'm wrong, but wouldn't this mean that I could have both drivers installed and switch between them on a per-application basis since I wouldn't need to change the kernel back-end driver?

[_ONH_]

Hopefully that means AMD users will finally be able to Fold natively in Linux on their gpu's like Nvidia users have been able to for awhile now.

The forme post with radeon-kdf does that and it is an alpha driver for hsa on Kaveri, so this should work in a year if amd finishes its hsa support as announced at the start of the year, but sadly no amd dev here comments on that, as far as I remember. To fold natively in linux would just need a hsa application of the project which not exist at time beeing.

[_ONH_]

Does this mean AMD plan a migration from Catalyst in the medium to long term if and when the FOSS drivers reach feature compatibility?

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.

[xeekei]

This is a step in the right direction. I'd prefer full open source, but I won't say no to just more open source. I wonder, why can't the release the shared parts with a permissive licence, and make it possible to install the "secret sauce" as binary extensions? Especially if it's just userspace extensions.

[blackout23]

I have come to suspect that the cause of the speed disadvantage both Nvidia and AMD closed drivers get on Linux as compared to Windows comes from the fact that they don't get KMS on Linux.

Well the NVIDIA Linux driver is exactly as fast as on Windows so that doesn't seem to be a problem.

[Luke]

Than perhaps Nivida could run faster on LInux than WIndows?

Well the NVIDIA Linux driver is exactly as fast as on Windows so that doesn't seem to be a problem.

If that's the case, Nvidia might be able to make their Linux blob beat the Windows framerate if they follow AMD's lead, given the fat-pig nature of WIndows 8. Then again, maybe that would screw up their business arrangements with Microsoft.

[DarkFoss]

The forme post with radeon-kdf does that and it is an alpha driver for hsa on Kaveri, so this should work in a year if amd finishes its hsa support as announced at the start of the year, but sadly no amd dev here comments on that, as far as I remember. To fold natively in linux would just need a hsa application of the project which not exist at time beeing.

Amd users shouldn't have to wait for HSA just to fold on their Gpu's. All Amd needs to do is fix their buggy OpenCl portion of the linux driver. According to Vijay Pande and proteneer anyway. I'd welcome using Catalyst until the open drivers were ready

[johnc]

My suspicion is that ultimately resources will be drawn down from the "full" Radeon driver and that part will, in time, die on the vine. Then FOSS fans will have to, in practice, accept a compromise of a half-free, half-non-free GPU driver. So I will be eagerly awaiting the FOSS fans here to express their outrage as they are so apt to do.

Trying to take a business perspective look at it, I'm sure saving money is one of the primary motivations. So having the community handle the kernel and X.org updates serves that end no doubt.

AMD must be in serious financial trouble.

[johnc]

If that's the case, Nvidia might be able to make their Linux blob beat the Windows framerate if they follow AMD's lead, given the fat-pig nature of WIndows 8. Then again, maybe that would screw up their business arrangements with Microsoft.

You are misled if you think the blob drivers don't have KMS support.