How Ubuntu 16.04 Is Performing With AMDGPU/Radeon Graphics Compared To Ubuntu 14.04 With FGLRX

[phoronix]

Phoronix: How Ubuntu 16.04 Is Performing With AMDGPU/Radeon Graphics Compared To Ubuntu 14.04 With FGLRX

With Ubuntu dropping support for the AMD fglrx/Catalyst driver in their upcoming 16.04 LTS "Xenial Xerus" release and manually installing the driver doesn't sound like an option, many have renewed interest in how the open-source Radeon driver stack is performing for Ubuntu 16.04 that's due out next month. In this article are benchmarks comparing the performance of Ubuntu 14.04.4 LTS (on both the open and closed drivers) to that of Ubuntu 16.04 LTS with the sole AMD Linux driver option on a variety of graphics cards.

http://www.phoronix.com/vr.php?view=22922

[eydee]

Any news of AMD planning to patch in missing features, like overdrive? Or is it simply dead for linux? How about application controlled vsync, which even Windows 95 can do?

[Michael]

Any news of AMD planning to patch in missing features, like overdrive? Or is it simply dead for linux? How about application controlled vsync, which even Windows 95 can do?

I haven't heard anything but maybe bridgman can enlighten us.

[SolidSteel144]

DPM is enabled by default with AMDGPU on 16.04?

[bridgman]

Not sure about specific control panel plans, but the general intention is to replace the Catalyst stack with a similar stack based on the all-open core.

Again, the breaking news here is not "only open source drivers forever", just "we're replacing Catalyst with hybrid stack and so current Catalyst is not going into 16.04".

[duby229]

So in other words, If you play synthetic benchmarks for fun use Catalyst, otherwise the OSS drivers will deliver many hundreds of FPS, so it is definitely good enough for almost everyone....


There still is the problem of OpenGL level of support, but with Catalyst being so broken it won't play most games anyway (and so buggy you can't stand using a desktop on it), it's only a matter of time before the OSS stack is able to play more games than Catalyst can.

[Veerappan]

I'm pretty happy with the way that radeonsi is shaping up against the outgoing catalyst code. There's still a few missing features/optimizations/bottlenecks, but it's getting there. I'll be happy when the OpenCL support is in better shape, and the eventual vulkan support will also be welcome, but pure GL features/performance are getting there.

Does anyone know which LLVM version is currently in the 16.04 archives? 3.8 or still 3.7?

[bug77]

I'm pretty happy with the way that radeonsi is shaping up against the outgoing catalyst code. There's still a few missing features/optimizations/bottlenecks, but it's getting there. I'll be happy when the OpenCL support is in better shape, and the eventual vulkan support will also be welcome, but pure GL features/performance are getting there.

Does anyone know which LLVM version is currently in the 16.04 archives? 3.8 or still 3.7?

Is there a scenario that could make you not "pretty happy" about how the open source driver is shaping up? Because from where I'm standing, it's about to replace fglrx and yet, after years in the making, it still can't beat fglrx across the board, despite fglrx being essentially abandoned for some time. But at least the open source driver has fewer features than fglrx does (see overdrive).

[tjaalton]

Does anyone know which LLVM version is currently in the 16.04 archives? 3.8 or still 3.7?

it has 3.8

[FLHerne]

Again, the breaking news here is not "only open source drivers forever", just "we're replacing Catalyst with hybrid stack and so current Catalyst is not going into 16.04".

The obvious question there is "why?".

The open driver is already so close to parity with your closed stack, and with so many @amd.com addresses on the mailing-list it's getting closer every week.
Getting a rewritten blob running on top of DRM can't be straightforward; I'd bet Mesa is (finally) at GL4.5 before it's done. Without dividing efforts, the latter could be done even sooner.

So why pick up the cost of developing and then maintaining two stacks in the long term, when one of those actually exists and works right now?