AMD's 2016 Linux driver plans (AnandTech)

Posted Dec 16, 2015 8:26 UTC (Wed) by adler187 (guest, #80400)
In reply to: AMD's 2016 Linux driver plans (AnandTech) by fandingo
Parent article: AMD's 2016 Linux driver plans (AnandTech)

The strategy as I understand it is to deprecated catalyst and move everyone to the open source drivers once it catches up. As a stop gap solution, they're working on replacing the out of tree kernel driver shipped with Catalyst to the AMDGPU driver.

Frankly, open sourcing the Catalyst drivers is not going to happen. First there's licensing issues and second it doesn't perform that great to begin with and seems to be pretty poor code from what I understand. It's probably easier to improve RadeonSI and Mesa than to deal with an open source Catalyst.

AMD's 2016 Linux driver plans (AnandTech)

Posted Dec 16, 2015 14:19 UTC (Wed) by fandingo (guest, #67019) [Link] (8 responses)

> The strategy as I understand it is to deprecated catalyst and move everyone to the open source drivers once it catches up. As a stop gap solution, they're working on replacing the out of tree kernel driver shipped with Catalyst to the AMDGPU driver.

Once it catches up? I'd say that it's far from certain that they can achieve performance parity with their Windows driver. The radeon project couldn't even get close.

> It's probably easier to improve RadeonSI and Mesa than to deal with an open source Catalyst.

And who's going to do that work? It might be easier in theory, but if they're not going to dedicate the resources to fixing FGLRX, why do you think they'll dedicate the necessary resources to fixing outside projects?

AMD's 2016 Linux driver plans (AnandTech)

Posted Dec 16, 2015 14:59 UTC (Wed) by Sesse (subscriber, #53779) [Link]

The problem is manpower. Creating a full-featured, performant OpenGL driver (for a single GPU family) is about 50 man-years, assuming you have competent people. As far as I know, no OSS team is nearly that well staffed. Mesa has some reusable parts, but also has to cater to everybody.

AMD's 2016 Linux driver plans (AnandTech)

Posted Dec 16, 2015 16:47 UTC (Wed) by drag (guest, #31333) [Link] (3 responses)

> And who's going to do that work?

Hopefully the guys they waste on FGLRX currently.

> It might be easier in theory, but if they're not going to dedicate the resources to fixing FGLRX,

Screw FGLRX. It's a shitty approach and it has never really worked that well. It's likely that it's not fixable.

It seems that the amount of resources devoted to the open source driver has yielded superior results to the much more resources they have been devoting to the closed source driver. Sometimes development methodologies actually do matter.

AMD's 2016 Linux driver plans (AnandTech)

Posted Dec 16, 2015 16:57 UTC (Wed) by fandingo (guest, #67019) [Link] (2 responses)

> Hopefully the guys they waste on FGLRX currently.

That's scary. Those people can't write decent software for any OS, and it's been that way since before AMD bought ATI.

AMD's 2016 Linux driver plans (AnandTech)

Posted Dec 21, 2015 13:36 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

Who's in charge of the Open Source driver? If it's not AMD guys, then if the fglrx guys are tasked with getting their code into the driver, they may be in for a rude awakening ...

Cheers,
Wol

AMD's 2016 Linux driver plans (AnandTech)

Posted Dec 21, 2015 15:53 UTC (Mon) by Felix (guest, #36445) [Link]

All major contributors for the (free) AMD Mesa/DRM driver are paid by AMD: Marek Olšák, Nicolai Hähnle, Christian König, Alex Deucher, Tom Stellard, Michel Dänzer, ...

And you can already see new contributors from AMD due to the amdgpu strategy like Chunming Zhou, Junwei Zhang, Sonny Jiang, Jammy Zhou, Ken Wang, Monk Liu, Flora Cui, Samuel Li and some others (just took random @amd.com names from the pull requests, probably quite a few).

And as you can see for the public reviews there is no "rude awakening". Just the usual "new dev gets acquainted to the (sometimes harsh, sometimes arbitrary) Linux kernel rules".

AMD's 2016 Linux driver plans (AnandTech)

Posted Dec 17, 2015 0:07 UTC (Thu) by adler187 (guest, #80400) [Link] (2 responses)

> > It's probably easier to improve RadeonSI and Mesa than to deal with an open source Catalyst.

> And who's going to do that work? It might be easier in theory, but if they're not going to dedicate the resources to fixing FGLRX, why do you think they'll dedicate the necessary resources to fixing outside projects?

https://www.phoronix.com/scan.php?page=news_item&px=A...

They're already funding at least 4 people, possibly more to work on just the open source Linux driver and Mesa, so they seem willing to dedicate resources to the task. In addition a few Catalyst developers have been working on the open source Linux efforts to get Catalyst up and running on AMDGPU. I think they've seen the writing on the wall with fglrx and put it in maintenance mode on Linux. As Mesa improves and fglrx gets further in to maintenance, they can redistribute those developers to Mesa/AMDGPU as well.

The problem for AMD is that their OpenGL performance is awful in Catalyst, on Windows as well as Linux. Nobody cares on Windows since 99% of developers use DirectX, so there's just not enough incentive from the Catalyst Windows team to fix their OpenGL code. So AMD's strategy going forward is to work on improving OpenGL in Mesa and move its Linux customers there, leave the OpenGL code to rot on Windows while continuing to invest in DirectX there, and push Vulkan to replace OpenGL on all platforms (which largely gets the driver out of the user's way and is supposed to fix the problems with OpenGL).

AMD's 2016 Linux driver plans (AnandTech)

Posted Dec 17, 2015 0:18 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Mesa is a looooong way from being competitive with fglrx on high-performance tasks.

The greatest threat to fglrx is not Mesa, it's Vulkan. With Vulkan drivers become radically simpler. Once you get all the buffer management and DRM ready, pretty much the only major remaining part is the shader compiler and AMD uses LLVM for that.

AMD's 2016 Linux driver plans (AnandTech)

Posted Dec 17, 2015 7:24 UTC (Thu) by adler187 (guest, #80400) [Link]

Yeah definitely agree on Vulkan. Also, since shaders in Vulkan are precompiled to SPIR-V IR, it's much easier to write a driver "compiler" than for GLSL.