Ubuntu Is Deprecating fglrx (Catalyst) In 16.04 LTS

[Charlie68]

With my notebook Acer E1 -522 with AMD Radeon HD 8280 graphics in Ubuntu 15.10 I tried both driver open that fglrx, the fglrx driver I have noticed several obvious bugs, while the open driver work well.

[directhex]

What stdc++ library conflict has to do with Mesa and RadeonSI? Curious.

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.

[Kraftwerk]

Ughhh some day in the future i would prolly welcome that move, but as it is atm heck no. This will be such a royal pain in the bum, guess i will stick with an older ubuntu as long as it works.

[mendieta]

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

Yes, Last year, I built my son a nice steam computer for very little money, with an SSD, inexpensive MoBo, and an AMD APU. Great value. But the software, oh boy. The fglrx driver breaks now and then, and because I use Linux since 1995, I can fix stuff like that. He could not. The Open Source stack runs super stable, but many steam games either don't run, or hit that libstdc++ issue, etc. So, I set him up with dual boot: 14.04 LTS + fglrx, and my strongly recommended, and default boot choice, 15.04 at the time (plus latest updates) plus open source stack.

After a couple months, I asked, and he had been manually booting to the LTS + fglrx, because the games just worked, and were faster.

So, I agree, for a generic desktop users, Open Source is great. But for a gamer with a hack around, you are still better off with fglrx. It sucks, but it's true. The whole thing sucks. My intel systems just work, it's all open source, no issues. But they are more expensive

[nir2142]

what if you are a gamer and want to use steam? ubuntu team think of that ??
open source performance are far far beyond the amd crimson . why not let the user choose in the installation if he want amd crimson or open source driver?? that the best solution !!!! extremely poor ergonomics

[Pecisk]

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.

Ok, this sounds like actually valid issue. I know C++ API issues with post GCC 4.9. DIdn't know Steam got bitten by it. I would go with Steam Runtime overriding usage of libstdc++ if that's possible. Is that fixable that way?

No big relation with Mesa capabilities, but I see what you mean by pointing this out.

[deve]

Is there a chance to see GL_ARB_geometry_shader4 in mesa? This is the adventage of proprietary drivers over mesa drivers. We use it in Supertuxkart for drawing shadows.

[directhex]

Is there a chance to see GL_ARB_geometry_shader4 in mesa? This is the adventage of proprietary drivers over mesa drivers. We use it in Supertuxkart for drawing shadows.

https://mesamatrix.net/

[axfelix]

That's been in Mesa since OpenGL 3.2, which was reached for most drivers in 2013...

[nanonyme]

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.

Well, the main problem is Steam runtime's retarded bundling of libstdc++. It works well if you run Steam on anything older than the Ubuntu version they target but if your libstdc++ is too new, tough luck. Debian stable + nVidia proprietary driver fits current Steam deployment scheme the best, probably