Linux 4.5 AMDGPU/Radeon vs. Catalyst OpenGL Performance

[phoronix]

Phoronix: Linux 4.5 AMDGPU/Radeon vs. Catalyst OpenGL Performance

With the first test release out this week for the Linux 4.5 kernel I have carried out some fresh benchmarks on different AMD Radeon graphics cards for comparing the very latest open-source driver performance against that of the proprietary AMD Linux driver. Here are how the competing AMD OpenGL Linux stacks are comparing to one another for starting off 2016.

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

[ObiWan]

So again your Fury is way slower as it should be.
Considering that other Fury owners, like myself and BenPope, already posted way higher benchmark results something has to be wrong there.

[Michael]

So again your Fury is way slower as it should be.
Considering that other Fury owners, like myself and BenPope, already posted way higher benchmark results something has to be wrong there.

Given how my R9 285 on the same AMDGPU setup is doing well, my vBIOS or something on the R9 Fury might be wonky or something. Bridgman also pointed out that it may be an issue with the R9 Fury not wanting to re-clock. Will try forcing it into a higher power state in next few days via sysfs to see what it does then.

[bridgman]

So again your Fury is way slower as it should be. Considering that other Fury owners, like myself and BenPope, already posted way higher benchmark results something has to be wrong there.

It may be card-specific. AFAIK we had not seen the performance drop in-house either, which made it tricky to investigate. Good news is that as of this morning we have a Nano in a compute rig which seems to be running quite a bit more slower than it should, so looking at clocks etc now.

[F1esDgSdUTYpm0iy]

10.2-dev? That should be 11.2-dev.

[Herem]

Most exciting out of these results today were how well the Radeon R9 285 (Tonga) graphics card is performing on the AMDGPU DRM driver now that there is PowerPlay. The speed in several of these tests were close to that of Catalyst and in fact for BioShock Infinite was even faster.

I'm impressed with the R9 285 results, espacially in BioShock! Was this without any visible differences in the rendering?

The Fury results weren't as impressive though. I've seen comments in previous threads from the AMD devs (@agd5f I think) suggesting Fury performance should be good when everything is installed and configured correctly, however looking at the results it's clear that either there's still something wrong or the Fury doesn't perform anywhere near its potential.

Can any of the AMD devs confirm that the Fury performance seen in these benchmarks is different to the results seen during internal tests? If so can they provide details of all the steps necessary for the Fury to achieve that level of performance?

[bridgman]

Can any of the AMD devs confirm that the Fury performance seen in these benchmarks is different to the results seen during internal tests? If so can they provide details of all the steps necessary for the Fury to achieve that level of performance?

Our in-house cards had been running faster (as had many in the field) but we have also heard reports from others about Fury not running as fast as it should with the amdgpu driver. As of this morning we have an in-house card reported to be running more slowly than it should in a compute rig, so hopefully that will help us figure out what is going on.

[bug77]

Our in-house cards had been running faster (as had many in the field) but we have also heard reports from others about Fury not running as fast as it should with the amdgpu driver. As of this morning we have an in-house card reported to be running more slowly than it should in a compute rig, so hopefully that will help us figure out what is going on.

Yeah, the kind of problem every developer loves: that one seen by everyone, but you.
Or like I often say P3 bugs are way worse than P1 or P2.

[pjezek]

Good luck, bridgeman!

[jrch2k8]

i suspect there is something else wrong with ubuntu 15.10 specifically(some in house ninja patch) or the way PTS register the FPS, i mean i have a r9-280(HD 7950) and the few times michael post his result on ubuntu my ArchLinux system trash it even though my CPU is quite weak compared to what michael usually uses([email protected][my mobo really really don't like overclock]).

so, if this is because of none of the above, i guess is related to the compilation process bypassing an optimization in mesa(there are several sse4.1+ paths) since i compile my mesa with -march=native or is related to the way PTS start storing the FPS, if you capture them too early mesa will stay at 0(or any random low number) while the upload occurs where FGLRX tends to stall at X fps while it uploads the CS(or crash depends the game).

if this is because of the latter, i guess someone can patch PTS to show the most common lowest FPS(should get rid of the uploads drops to some extent), the average(with only values > than the second most common lowest fps) and the highest FPS or add some form of delay to benchmarks the game when all the upload is done(is kinda though) or we wait until mesa get its shader cache and the upload manager gets its own thread to fix the stall