AMDGPU vs. Radeon DRM Driver Performance On Linux 4.15

[phoronix]

Phoronix: AMDGPU vs. Radeon DRM Driver Performance On Linux 4.15

For GCN 1.0 "Southern Islands" and GCN 1.1 "Sea Islands" graphics processors from AMD, they are supported both by the Radeon DRM driver (the default) as well as the AMDGPU DRM driver (designed for GCN 1.2+ GPUs). As it's been a while since comparing the performance impact of changing the kernel driver for these older GCN graphics cards, here are some fresh benchmarks using the Linux 4.15 Git kernel with Mesa 17.4-dev using a few GCN 1.0/1.1 cards.

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

[bridgman]

Thanks for running these. The Vulkan vs OpenGL results for R9 290 are very interesting (and potentially valuable).

[turboNOMAD]

I have an R9 290 which I use both for Native and Wine gaming. Does not seem to be regressed, although I use Arch Linux + mesa-git + llvm-svn.

Any chance of AMDGPU getting declared "stable" for GCN 1.1 in the near future? I'm still using radeon, didn't bother to mess with kernel parameters.

[FireBurn]

I have an R9 290 which I use both for Native and Wine gaming. Does not seem to be regressed, although I use Arch Linux + mesa-git + llvm-svn.

Any chance of AMDGPU getting declared "stable" for GCN 1.1 in the near future? I'm still using radeon, didn't bother to mess with kernel parameters.

That's up to your distro

[R41N3R]

In Arch Linux it is usually not like that. If upstream declares AMDGPU as stable, Arch Linux will follow.

From my point of view it make sense as well to enable AMDGPU at some point as the default for these cards in the not to distant future to avoid confusion, reduce driver paths and to provide RADV.

[valici]

The 290 is a quantic card. It's performance is normal and broken at the same time and only when you observe it, it will decide it's state.

[ScarecrowDM]

Yeah, performance is better overall with my R9 280X under amdgpu.
But I have random lockups with it while gaming\media and browsing, so I'll stick with radeon for a while.

These hard lockups happens both with mesa-dev (LLVM 6.0.0 / 17.4) and stable (LLVM 5.0.0 / 17.3). I have yet to test it with kernel 4.15 though.

[Holograph]

AMD, you're not going to convince me to buy more of your products if you don't friggin fix Hawaii. I don't like being treated like a third-class citizen (first-class = Windows, second-class = Linux not using Hawaii, third-class = Linux using Hawaii). How much patience must we have for our cards to work? Seriously, how long is it going to take to fix this issue?

Is the expected result of all these problems that I should think, "gee, my existing card I paid hundreds for doesn't have good performance at all, so I guess I'll pay hundreds more for another one and hope THAT card works!"? Because that isn't going to happen. But I'll keep posting about it, no problem. Because as time continues to pass, it makes AMD look worse and worse as this problem is ignored, and makes me feel worse and worse as a customer of AMD's.

[turboNOMAD]

In Arch Linux it is usually not like that. If upstream declares AMDGPU as stable, Arch Linux will follow.

From my point of view it make sense as well to enable AMDGPU at some point as the default for these cards in the not to distant future to avoid confusion, reduce driver paths and to provide RADV.

You are correct, Arch packages kernels (and all other packages for that matter) exactly in the same configuration as they come from upstream.
This is exactly why I'm asking here, knowing that AMD/Mesa/Xorg developers frequently visit this forum.

[LinAGKar]

Typo:

The AMDGPU support for GCN 1.0/1.1 remains experimental but with recent kernels can be easily enabled via the radeon.si_support=0 amdgpu.si_support=1 kernel command-line switches for GCN 1.0 GPUs or radeon.cik_support=0 radeon.cik_support=1 for GCN 1.1 GPUs.