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

[Nille]

I like the idea of sharing the same kernel module. I don't think its a big problem to backport the FOSS-Module and Package it with DKMS.

I have only concerns about the Driver Features. In the past there was a different Driver for Windows and Linux. The Linux Driver was horrible outdated and it take month for get new Hardware Supported.

[entropy]

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

I don't see the point. Intel's IGPs are still nowhere near competitive to NVidia's and AMD's GPUs.

[pinguinpc]

In fairness, we did send a Kaveri system. Not a "card" technically, but it is hardware

This is good step and now must be continues with send vga cards

Maybe for amd linux at now dont represent major market than windows (this is important because amd dont have enough money resources than intel or nvidia) but step by step linux gains more attention

Phoronix is a few sites dedicated to hardware linux reviews and other things

Personally i believe amd opensource driver had many posibilities especially on compatibility than propietary, however amd propietary driver have more performance than opensource

But if opensource driver have enough time (around 2 years), is very possible see very positive results

[Luke]

This could boost Catalyst performance quite a bit

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. I don't know what kind of arrangement they use on Windows, but I read somewhere that running in UMS could cost them as much as 20%. Yes, that means our Mesa drivers fall behind again-but not by getting any slower. Instead, more AMD attention to a now-open kernel module should speed them up too.

Use of the (or a new) open source KMS kernel side module could also mean full feature and compatability parity with the open drivers in terms of display servers (mir/wayland), Plymouth working right by default, that sort of thing. Care to guess what kind of pressure that puts on Nvidia to play ball with the Nouveau team? If they don't follow suit they risk being left behind, and the speedup this could bring AMD's upcoming smaller blob could give Nvidia's blob a reputation for not keeping up and getting slow.

This also had the advantage of getting unauditable closed code out of the kernel on top of all else.

[pingufunkybeat]

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!

[edoantonioco]

Could this be a possibility to re-enable the catalyst-legacy driver? I think than probably the code than interact directly with the kernel will be from the r600 driver, so not too much problem. Of course, there is something named "Planned obsolescence", so that could be a problem.

[iznogood]

I believe it's a bad decision if it happens. If amd can give 90% of catalyst performance on r600 with just a few devs then imagine what they can do with only a couple more. And if the hardware did not change that much on southern islands then we would have even better results since they would focus more on the existing codebase instead of writing the radeon si driver.
This would probably require massive changes on the catalyst code or some "glue" library.

Why not use the gallium driver on Windows instead? The codebase must be 20 times less than catalyst and if I am not mistaken the design is cross os (winsys ?)

[Anarchy]

Linux is also used in a lot of computing environments. Having a worse driver and support is not a good thing.
Doing this would give them more opportunities in high performance Linux environments.

AMD GPUs are completely irrelevant in HPC environments. Also their CPUs fast are getting to be the worse choices from every perspective. Recently at my university the HPC group replaced all AMD hardware with xeons and added xeon phi cards for testing. Yeah... Everyone experienced speed increases from from two and up to ten times depending on workload.

Which is kinda sad considering that AMD had big revenues from HPC parties several years ago.

[DarkFoss]

I loved seeing this:Besides the OpenGL driver being under this new model, the Catalyst OpenCL components would also be reworked.
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.

[agd5f]

What about Intel? AFAIK Intel graphics driver is totally open. Does Intel has any disadvantages right now because of this?
I can't see why AMD don't drop Catalyst and put efforts just in Radeon. Maybe something related to DRM (Digital Management Rights). Anyway, it's a good step in the ridht direction.

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.