As simple as in summary. This package package is dead upstream. AMD now focusing on hybrid amdgpu driver and open-source driver now is mature enough. Maintaining massive backports, while there is no any upstream involving, and specially with new kernels is something beyond sanity level. Gamers and others who think fglrx 3-D capabilities needed, can get ebuild from elsewhere. (x11-overlay, etc). This package is notorious of having severe problems. Need discussion. Reproducible: Always
not really an indicator but: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#fglrx
From AMD graphics developers: Correct. We are starting to wind down Catalyst Linux and focus on amdgpu-based stacks instead. That means the 16.04 release will ship with just the all-open stacks, but with hybrid stacks following soon. The intent is to give you all the things you like about the open source stack plus the gaming performance of Linux Catalyst.
They are still supported with old kernels and I think current mesa does not deliver the same performance and level of OpenGL. I'd vote for keeping it at least until this December.
supported with old kernels is very uncertain. Speaking of maintaing policy -- Then, ebuild has to restrict deps on kernels to avoid horrible mess with very recent kernels, which is what unaware users always tend to use, then complain about this drivers every now and then. I never against outdated and not much supported by upstream as long as they: 1. compiled with the all range of shipped kernels (by Gentoo) 2. compiled with all range of gcc/glibc/headers shipped (by Gentoo) 3. works on hardened 4. includes proprietary EGL/GLES libs by AMD, this is what ebuild has never provided. 5. besides compilation, does not exhibit runtime problems due to various reasons (including all sorts of custom patches ebuild includes). Currently almost none of above mentioned points seems respected by ebuild.
I just want to make sure the package is not removed until mesa provides the same level on OpenGL and people have a choice. To 1. Restricting a kernel version is difficult, because you can't do that during dependency resolution time (as the kernel might be different from the current one). I'm happy to apply patches that add a warning if an unsupported kernel version is currently running on that machine. To 2. Applies here as well. To 3. We can mask it on hardened profiles if it causes breakage there. To 4. How can we fix this? Is there a bug? How do other distributions solve it, if they do? To 5. The number of bugs regarding runtime issues is still low. I suggest the following steps to deprecate it properly (we will probably get feedback from users we haven't thought of): - Create a news item that suggests to migrate over to xf86-video-ati/mesa stack - Stable.Mask VIDEO_CARDS="fglrx" - Mask ati-drivers package - Wait - Remove it
I've started the process.
Last rites for x11-drivers/ati-drivers, x11-libs/amd-adl-sdk, x11-libs/xvba-video sent.
Just want to note that the popular R9 280X GPU series still isn't supported by the amdgpu driver. Personally I'm dependent on the fglrx driver because of the OpenCL support.
(In reply to Reinhard Biegel from comment #8) > Just want to note that the popular R9 280X GPU series still isn't supported > by the amdgpu driver. Personally I'm dependent on the fglrx driver because > of the OpenCL support. I recommend trying the Mesa drivers. That's pretty bad that AMD has stopped maintaining support for the R9 280X (and fglrx). Unfortunately because they stopped maintaining fglrx, it doesn't support recent xservers or kernels. It's not possible for us to continue maintaining it. If the Mesa drivers aren't sufficient, I recommend copying the ati-drivers into a local overlay.
In my humble opinion it would be better to wait on this at least until the DAL/DC code for the new amdgpu driver is merged into the mainline kernel. Until that happens, there are some features, like DP MST support, HDMI audio, etc., which are only supported with the fglrx driver. Also, support for GCN 1.0 and 1.1 cards in amdgpu is still experimental (and disabled by default in the kernel config), GCN 1.0 support especially so as it was only just added in kernel 4.9 (this includes the R9 280X, which a previous commenter had said wasn't supported). The open source driver is improving with each new kernel version, but is still not a complete replacement for some configurations. And while this driver may be dead upstream, it still works fine (at least, mostly fine), so long as Xorg 1.17 or older is used. It *does* work with newer kernels, at least through 4.9 (the latest stable version as of this writing - I haven't tested it with 4.10 git), so long as the appropriate patches are applied (posted on bug #583574). Since it still works, I think it would be a mistake to remove it until the replacement is fully ready, especially as it doesn't look like it will be too much longer before that happens. Obviously it's preferable to use the open-source amdgpu driver (or radeon for older cards), but unfortunately that's not an option for everyone yet. In the meantime, fglrx remains a viable alternative, and should be preserved as a stopgap option until amdgpu has improved a little more. The DC/DAL code has taken longer than anticipated to get accepted, but with the release of the new Vega GPUs this year there'll be a lot of pressure to get it merged ASAP. And with another few kernel versions, the GCN 1.0/1.1 support in amdgpu should become less experimental and more stable. Perhaps instead of deleting this driver outright, it could simply be masked, with a warning message that it is no longer supported upstream and that the user should use the open-source amdgpu or radeon drivers instead if at all possible. Then perhaps a few kernel versions down the road, the open-source drivers will have improved to the point that no one needs fglrx anymore, and the issue can be revisited.
(In reply to adebeus from comment #10) I would be willing to consider that if someone stepped up and maintained it. As it is, it is under the x11@ umbrella but without an actual maintainer since before the transition to git (it should never have been under the x11 umbrella, like nvidia-drivers). As it currently stands, it has 26 open bugs, no maintainer, doesn't support recent xservers, doesn't support recent kernels, and is unmaintained upstream for more than a year, and at least two of those are unfixable.
I would be willing to step up as maintainer as long as it is understood that I can't do anything about (1) upstream or (2) xorg 1.18 compatibility. I currently use an HD 6950 which is pre-GCN and therefore outside the coverage of amdgpu. I would also expect it to remain masked and only kept in tree for the benefit for the small percentage of OpenCL users. I have not maintained an in-tree package before so would request proxy maintainership. As one doesn't exist, should I open a maintainer bug?
(In reply to dosfreak622 from comment #12) > I would be willing to step up as maintainer as long as it is understood that > I can't do anything about (1) upstream or (2) xorg 1.18 compatibility. I > currently use an HD 6950 which is pre-GCN and therefore outside the coverage > of amdgpu. I would also expect it to remain masked and only kept in tree for > the benefit for the small percentage of OpenCL users. > > I have not maintained an in-tree package before so would request proxy > maintainership. As one doesn't exist, should I open a maintainer bug? To be honest, I haven't had good experiences with maintainers by proxy. For one, it's partly how we got into this situation. I'm thinking the best thing to do is to offer a Gentoo-hosted ebuild repo for ati-drivers. Whoever wishes to maintain it can do so, all without me being involved :) Alternatively, someone could create such a thing on GitHub today, as they could have at any point in the past year...
You could become proxy maintainer of ati-drivers if you wish. x11 would then no longer be involved with this package. https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
I have put in a maintainership request with Bug #586370.
(In reply to dosfreak622 from comment #15) > I have put in a maintainership request with Bug #586370. Ignore this bug number, I pasted the number of an unrelated bug.
xvba-video and amd-adl-sdk have been removed. commit 4013aef499795f1a632cfc8475f84783d9a319d5 Author: Matt Turner <mattst88@gentoo.org> Date: Sat Feb 25 12:41:39 2017 -0800 package.mask: Drop masks for removed xvba-video and amd-adl-sdk. Bug: https://bugs.gentoo.org/582406 commit 02fb0642f0e45d4963322bbab702c01364b4c66b Author: Matt Turner <mattst88@gentoo.org> Date: Sat Feb 25 12:41:02 2017 -0800 x11-libs/amd-adl-sdk: Remove. Bug: https://bugs.gentoo.org/582406 commit 817b5ef23634866ff323b0b1249e7e192078bbeb Author: Matt Turner <mattst88@gentoo.org> Date: Sat Feb 25 12:40:12 2017 -0800 x11-libs/xvba-video: Remove. Bug: https://bugs.gentoo.org/582406
dosfreak622 said s/he was going to maintain ati-drivers by proxy, something I wasn't particularly interested in doing but was willing to give a try. Unfortunately (or otherwise), nothing has come of this, and it's been two weeks since s/he was supposed to be back. So, removed: commit 42247d339a9338c3090d085ed5eb92780922f3ba Author: Matt Turner <mattst88@gentoo.org> Date: Wed Mar 15 12:28:26 2017 -0700 package.mask: Drop mask for removed x11-drivers/ati-drivers Bug: https://bugs.gentoo.org/582406 commit 86b3b7bb116082a775ff13496065bdaf971ac8cd Author: Matt Turner <mattst88@gentoo.org> Date: Wed Mar 15 12:27:04 2017 -0700 x11-drivers/ati-drivers: Remove package Bug: https://bugs.gentoo.org/582406 FWIW, open bugs at the time of removal: Bug 393177 hardened ati-drivers don't work with PAX enabled Bug 461798 x11 x11-drivers/ati-drivers-13.1: check if CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR is disabled, paxmark /opt/bin/aticonfig Bug 485846 x11 x11-drivers/ati-drivers - Warning "CONFIG_DRM must be disabled ... " is incorrect Bug 487792 x11 x11-drivers/ati-drivers - Memory leak with kernels >= 3.10 Bug 562508 x11 >=x11-drivers/ati-drivers-15.7 - support installation without X bug 582406 x11 deprecate (tree-clean) x11-drivers/ati-drivers Bug 583574 x11 x11-drivers/ati-drivers-15.12-r1 doesn't build with new kernels Bug 609504 proxy-maint Maintainership request: x11-drivers/ati-drivers
