Ubuntu Is Deprecating fglrx (Catalyst) In 16.04 LTS

[darkbasic]

This is an awesome news, do you know if Ubuntu finally decided to enable vaapi/vdpau for open source gallium drivers?

[zzarko]

For those who don't know, I manage AMD's open source graphics team. We (AMD) are focusing our Linux graphics driver development on the amdgpu based open source and upcoming hybrid stacks; consequently, we are not supporting fglrx on Ubuntu 16.04 LTS. Users who require Pro-graphics or Workstation class features and performance can continue to use fglrx on Ubuntu 14.04 until the hybrid stack is available later this year.

Do you have any information what would happend with GCN 1.0/1.1 support? A few years back I bought 7950 (it sounded as a right decision at a time), and it is serving me well for my Linux gaming (with fglrx). I have tried open source driver, and most of the Steam games that I play are not working (there are exceptions, of course, even one game that works on open source drivers, but not on fglrx).

Open source performance is (for me) good enough for games that work with it, but the problem is that many of them don't. On numerous occasions I have read that GCN 1.0/1.1 won't be supported by AMDGPU. Does this mean that I should buy a new card if I want to continue to play games (although the current card and drivers that I use are more than capable)? This looks to me like a middle finger to some of your customers, but I still hope I'm wrong...

[linuxforall]

If you have been using rolling release distro like debian testing, there is nothing suicidal with software changes. Amd crimson works with Arch linux patches with kernel 4.5 and you do not have to update xorg to 1.18. In debian it is easy to downgrade xorg, if you do a fresh debian testing install.

https://hackedbellini.org/linux/downgrade-and-force-some-packages-on-debian-to-a-previous-version/

In debian they have not tested fglrx packages, so they are crap. Also with many packages it is more complex to uninstall the driver than using aticonfig --uninstall. Use the .run file from amd and nvidia site when installing, then you have full control to the source code.

I do but only issue is Arch so far don't play happy with my 4790K Haswell driving it to full turbo mode with no scaling due to Arch kernel 300Hz config. Will try Siduction instead to replace Arch.

[deve]

I think they haven't implemented it, since they already have geometry shaders in core OpenGL 3.2, which offers the same functionality at least. So why don't you just use core geometry shaders?

Tbh. I don't know why this one particular extension has been used. It was rather minor problem because on linux it wasn't available only for intel graphics cards, which were not that powerful anyway. On windows it's available for intel/nvidia/amd.

Now if we are switching from fglrx to mesa, it won't work for much more people, so maybe we should try to find better solution in STK.

[Hi-Angel]

So, this is official...? fglrx has been deprecated by AMD? WTF? What about older cards and OpenGL 4.5 / OpenCL (in R600), ...?

As an owner of one of those R600 cards (HD5730), I ran a few months ago tests to compare performance of the latest FGLRX (from the site) and the development Mesa (from one of PPAs). Turns out, Mesa is faster. And this is not to mention a bunch of bugs in FGLRX.

So don't worry, as AMD devs are focusing on Mesa, there's really no need in FGLRX anymore, it's not even competitive.

[tjaalton]

This is an awesome news, do you know if Ubuntu finally decided to enable vaapi/vdpau for open source gallium drivers?

not going to happen for 16.04, requires a lot of packages to move universe->main, like ffmpeg which itself would pull around 30 packages, but I'll consider providing a more full-featured mesa build in a semi-official PPA

[linuxforall]

It is just a simple config opton in make xconfig. I use kernels from kernel.org and I tune them way I like. I have overclocked this wait timer too from 250Hz to 300Hz and everthing works fine with Amd A8-7600. I have set cpu core freq scaling to fixed perfromance in the linux configuration, A8-7600 overclocks from 3.1Ghz to 3.8Ghz under load automatically.

In past early days of Linux I would always compile my own kernel and drivers if necessary but lately stock kernels from Canonical or Red Hat have got quite good so never felt the need. The issue is peculiar to the 300Hz tick of Arch kernel where CPU stops scaling with Haswell and even Skylake and newer CPUs. Its a Pstate and config Hz scenario. AMD doesn't use pstate so works fine with 300Hz config in Arch.

[unixfan2001]

The Mesa DRI modules are linked against libstdc++ (see `ldd ldd /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so`)

libstdc++ has a weak ABI represented outside its soname - apps linked against libstdc++ X will not work with libstdc++ X-1 even though both are libstdc++.so.6

Games on Steam run with the "Steam Runtime" shunted into the linker path via LD_LIBRARY_PATH. "Steam Runtime" is a collection of libraries of guaranteed minimum versions - so a game developer can compile against the Steam Runtime, and their game should work on any distribution regardless of the library versions in that distribution.

Steam Runtime contains libstdc++ version GLIBCXX_3.4.19 (GCC 4.8.3)

If your distro mesa uses dynamic linking (all but SteamOS do), and was compiled with GCC 4.9.0 or higher, the Steam Runtime loading triggers an ABI mismatch and will cause DRI to fail to load, and 3D acceleration to fail.

The normal workaround is for users to delete libstdc++ (and libgcc) from their Steam Runtime folder, on Mesa systems.

That's not quite right. The normal workaround is to add an LD_PRELOAD to Steam's .desktop shortcut. You only have to do that once VS constantly deleting a reemerging library.

Here's what the exec line looks like on my Ubuntu 16.04 machine (the libasound part deals with an issue that kept 99% of all games from launching properly. Seems to be fixed with the latest update though):

Exec=env LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libasound.so.2' DISPLAY=:0 steam

[unixfan2001]

They are slow and full of unneeded network server stuff. Even former red hat poetterising linux guy recommends custom kernels.

https://freedesktop.org/wiki/Software/systemd/Optimizations/

"Don't use debug kernels. Debug kernels are slow. Fedora exclusively uses debug kernels during the development phase of each release"

It's Poettering. And why former? AFAIK, he's still with Red Hat.

[Passso]

This will bring AMD even lower on Linux market share...
From my recent experiences the open source driver is far to be optimal in performance and features.

Don't get me wrong it is still very good for desktop and most gamers, but for big gamers the ROI is bad.
Now I hope AMD will pump up their OSS team and come back in the race, NVidia is now the only rational choice and I do not like the lack of competition.