> My Asus Netbook no longer gets all the acceleration options that it used to have pre 16.04.
Which holds true, because /dev/radeon no longer offers hardware video decoding support it once did unless I force enable it, and even then it usually leads to random X crashes when watching videos.
And then there is this,
"For one, AMD users can’t use applications that require OpenGL 4.3 or later without the fglrx/Catalyst drivers."
OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux. You can use fglrx with newer kernels just fine, it's just that user space went out of it's way to break support.
I really fail to see how that has anything to do with Linux's unstable kernel driver API.
> OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux.
Ah, the Linux evangelist blame-game. It's a big advantage of a system being so haphazardly thrown together from separately developed components. Start by blaming the choice of distro, end up at "Linux is just a kernel".
I mean, I feel like that's valid in the context of this discussion. That being 'Linux's unstable driver API designed to push drivers as source into mainline causes ISVs headaches'.
How does that apply here when Linux didn't change and you can still use the same kernel driver, but some other component decided to not work with the driver anymore?
... a brand new, mainline kernel will run fglrx just fine. It's user space (specifically the x srever) that decided to break fglrx. So how is that the fault of the kernel's unstable API again?