AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver

[phoronix]

Phoronix: AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver

Alex Deucher of AMD has taken the floor at XDC2014, which got underway today in France to provide an update on the company's new unified open-source driver strategy. Compared to what I originally reported earlier in the year when breaking the news, there's some notable changes but overall this is an exciting endeavor for AMD Linux customers with the open and closed source AMD GPU drivers going to share the same (open-source) Linux kernel driver.

http://www.phoronix.com/vr.php?view=21006

[darkbasic]

Holy shit, finally some good news! It would be very interesting to know if they plan to enlarge their FOSS team.

[blackout23]

This driver model still seems a bit inflexible. Imagine NVIDIA doing the same thing. They could roll out a new version of their closed source OpenGL implementation easily, which is good, but other features (think G-Sync etc.) are bound to the kernel version and release schedule (and indirectly the schedule of distros). On Windows AMD and NVIDIA can just roll out stuff whenever they want and it just works. Companies need a direct path to their users/customers and the OS and distros should not get into their way like this.

[BreezeDM]

I think this way could be better for their Linux drivers in the long run. However, I am concerned that if the Windows and Linux drivers won't share the same code, features won't be implemented in the Linux drivers and it will just add another driver to support with it's own idiosyncrasies. Supporting another driver code base might be too expensive for AMD unless they get a lot of outside help from the community.

[rober]

This driver model still seems a bit inflexible. Imagine NVIDIA doing the same thing. They could roll out a new version of their closed source OpenGL implementation easily, which is good, but other features (think G-Sync etc.) are bound to the kernel version and release schedule (and indirectly the schedule of distros). On Windows AMD and NVIDIA can just roll out stuff whenever they want and it just works. Companies need a direct path to their users/customers and the OS and distros should not get into their way like this.

I think that's a distro's problem, if companies join a FOSS model (more tied to Linux kernel development), newer hardware that is not available in the market will reach to the Linux kernel faster, before user can actually buy the hardware (like what Intel is doing for its next generation of CPUs). In that case, users will need some love from the distributions to get updated with latest kernels faster.

[darkbasic]

This driver model still seems a bit inflexible. Imagine NVIDIA doing the same thing. They could roll out a new version of their closed source OpenGL implementation easily, which is good, but other features (think G-Sync etc.) are bound to the kernel version and release schedule (and indirectly the schedule of distros). On Windows AMD and NVIDIA can just roll out stuff whenever they want and it just works. Companies need a direct path to their users/customers and the OS and distros should not get into their way like this.

Did you ever hear about DKMS?

[blackout23]

Did you ever hear about DKMS?

What do you need DKMS for, when you have a kernel driver mainlined?

[pixo]

If they supported current gen HW I would be really happy.
I don`t want to have to upgrade my R9 290 nor R7 260.

[somini]

This driver model still seems a bit inflexible. Imagine NVIDIA doing the same thing. They could roll out a new version of their closed source OpenGL implementation easily, which is good, but other features (think G-Sync etc.) are bound to the kernel version and release schedule (and indirectly the schedule of distros). On Windows AMD and NVIDIA can just roll out stuff whenever they want and it just works. Companies need a direct path to their users/customers and the OS and distros should not get into their way like this.

You call it "distro getting in the way", I call it "assurance that some brainfart by some of their employees doesn't crash my kernel".

[Veerappan]

I think this way could be better for their Linux drivers in the long run. However, I am concerned that if the Windows and Linux drivers won't share the same code, features won't be implemented in the Linux drivers and it will just add another driver to support with it's own idiosyncrasies. Supporting another driver code base might be too expensive for AMD unless they get a lot of outside help from the community.

From what I understand, the existing Catalyst kernel driver and X.org driver are the few things that aren't shared with the Windows/Mac driver. So the GL compiler, CL runtime, CL Compiler, etc for Catalyst will still be sharing code with the windows driver, but the kernel/X.org drivers which were custom for *NIX anyway will now be sharing development with the open-source driver.

So what used to be shared with windows will still be shared, and the open-source drivers will now get to share some (more?) development resources with the closed driver.

EDIT: And now that I think of it, this might also open up the way to Catalyst on BSD.