AMDGPU-PRO 16.40 Released For Ubuntu & Red Hat Linux Systems

[Charlie68]

I did not understand that I'm using driver and if I could improve performance, my notebook features an AMD Radeon HD8280 on Ubuntu 16.04. Sorry for English, hello.

[Mystro256]

Looking into it further... looks like only Fedora 22 (using the redhat 7.2 package) is supported. It maybe able to be worked around by extracting the packages manually.

[boltronics]

I'll have to see if they finally fixed the LEDs on the Fury X. They used to work with fglrx, and AMDGPU-PRO broke them.

[flubba86]

I just installed this on Ubuntu 16.04. I managed to get the DKMS module to compile on linux kernel 4.8, using the same patch set that worked on the AMDGPU-PRO 16.30 releases (see here: https://github.com/Lucretia/vulkan-o...16.30.3-315407) though two fewer patches were needed due to some minor modernization of the source over the 16.30 series.

However, I did have one problem, and it was a big one:

PSA! This driver does not work on Xorg Server v 1.18.4-0ubuntu0.1 which is the latest available for Ubuntu 16.04! These two files: /opt/amdgpu-pro/lib/xorg/modules/libglamorgl.so and /opt/amdgpu-pro/lib/xorg/modules/extensions/libglx.so both segfault and crash the Xserver. I spent 2 hours this morning swearing and debugging what was causing it.

Finally, downgrading xserver-xorg-core to v 1.18.3-1ubuntu2 fixed it.

[dungeon]

I did not understand that I'm using driver and if I could improve performance, my notebook features an AMD Radeon HD8280 on Ubuntu 16.04. Sorry for English, hello.

AMD does not like writting changelogs nor take attention on descriptions, etc... Whatever, that is Kabini APU so should work. As per ddx package description:

AMD/ATI Radeon display driver
This package provides the 'amdgpu' driver for the AMD/ATI cards. The
following chips should be supported: KAVERY, KABINI, CZ.

And no, that Y is not mine typo

[dungeon]

These two files: /opt/amdgpu-pro/lib/xorg/modules/libglamorgl.so and /opt/amdgpu-pro/lib/xorg/modules/extensions/libglx.so both segfault and crash the Xserver. I spent 2 hours this morning swearing and debugging what was causing it.

That libglx.so package says "xorg GLX exetnsion"

When descriptions has typos like that i can only guess how code looks like, so it is probably a typo bug there too

[flubba86]

That libglx.so package says "xorg GLX exetnsion"

When descriptions has typos like that i can only guess how code looks like, so it is probably a typo bug there too

While I chuckle to think the code is full of spelling mistakes, I think the problem is likely due to a more technical reason.

I believe the xorg modules and extensions need to be linked against xorg development headers when they are compiled. Since Ubuntu 16.04 was released, it has used xorg server v 1.18.1, then 1.18.2, and then 1.18.3. AMD would need to update their source for every new version released, and make modifications to get it working on a newer version. Luckly the changes required in the minor point releases are very small and are non-breaking. Xorg server v 1.18.4 was pushed out to Ubuntu 16.04 on the 5th of October, likely after this release was already compiled, packaged, and in testing. The changelog for the ubuntu release of xorg server v1.18.4 mentions "update to upstream version" so it is possibly a larger change than the other minor point releases, and this AMDGPU-PRO driver simply isn't compatible with it.

[dungeon]

So profiles adds Tomb Raider, Euro Truck Simulator 2 (but i guess that works with American Truck Simulator too if you rename it ) and Autodesk Mudbox profiled.

OMX setup fine i guess, also seems 32bit OS Ubuntu now supported, hmm... didn't expected that one

But it was always like that user need to explore and figure out what is really new and as always more eyes spot things better

[dungeon]

Does Unigine Heaven windows benchmark work with wine-staging csmt enabled at fullhd and ultra without hanging xserver? Or a windows game?

Why you are interested in that with Testing, there is a planed transition to 1.19 server in Debian...

https://release.debian.org/transitions/

so you probably have some unreleated bugs due to transition prerequisites

[starshipeleven]

Why do AMD even keep working on proprietary stacks? They (the stack) are slow, support is awful, and performance falls behind AMDGPU in a lot of games.

Because companies don't usually use bleeding edge kernels.

For any open driver to trickle down to RHEL you'd have to upgrade to a new version and hope RedHat has deemed it stable enough for company use.

If they focused only on OSS drivers we would already have premium OSS: Kernel drivers, OpenGL drivers, OpenCL, Vulkan, etc.

With all due respect to AMD, but company usecase is probably the one where most $$$ is, so they have to.