AMD Radeon RX 480 On Linux

[pszilard]

I may have missed your original point as well (I didn't knowingly ignore it) - what do you think is broken/flawed about the current OpenCL testing other than the need for additional/different tests ?

As I noted above the Mixbench numbers are useless without specifying at least the flops/byte ration they run at. However what really matters is the GFlops as a function of Flops/byte (or GB/s), just as the author of Mixbench presents his/her data: https://github.com/ekondis/mixbench

That makes the OpenCL section 50% flawed and 50% not too relevant (MD5 results), right?


@bridgman: unrelated, but I was wondering. What's the OpenCL compiler in this new AMDGPU-PRO stack, how much of the code-base (in particular compute-related) is shared with the ROC stack? And what's the situation with the OpenCL support in the ROC stack? It's not entirely clear what the different components are/do.
We've suffered from serious driver overheads as well as crazy compiler behavior in our code so I'm looking forward to seeing the ROC stack in action, both for a more lightweight compute-tuned driver stack as well as for a better compiler. We know our kernels can match the NVIDIA CUDA kernels that have been getting tweaks and serious tuning for years (at Maxwell with Fiji), so it's pretty frustrating to be held back by the software stack.

[bridgman]

The ideal GPU configuration, particularly "ALU power vs everything else (ROPs, texturing, geometry)", has been changing pretty heavily over time. We generally try to be ahead of the curve while our competitors tend to be behind the curve in that regard. We think that making slightly forward-looking hardware is the right thing to do, but backwards-looking hardware is a heck of a lot easier to sell.

It seems to be generally accepted that AMD GPUs tend to perform better over time relative to the competition as workloads evolve (within the typical timeframe that someone actively uses a new board), but somehow everyone seems to forget this with each new generation of hardware.

I do sometimes wish we could put a couple of backwards-looking GPU configurations in our lineup, not because they are the right thing to offer but because it would spike the "oh the only thing that matters is performance on last years games; scores on the latest games couldn't possibly be a leading indicator of real world performance" thinking that seems to come with every new product launch.

A much better analogy than IPC would be the CPU power vs memory vs IO tradeoffs when matching server designs to workloads.

[arunbupathy]

I don't why people are suddenly worried about this. I remember seeing an old GTX960 review where it showed that the card also exceeded PCI power draw standards. I doubt many cards stay within spec. All of a sudden this turns into an issue.

Actually I'm worried that it will damage AMD's image more than the motherboard!

[Passso]

I thought mining has been a net loss on GPUs for a while as soon as you factor in electricity costs. Has that changed?

Home mining is dead yes. It is not even a lottery anymore with 10 Titan X running 24/7.

Watch here the kind of specialized procs that groups now use:

https://en.bitcoin.it/wiki/Mining_hardware_comparison

For lazy people :

Titan X ~ 240 Mhash/s
Antminer S5+ ~ 7 700 000 Mhash/s

(Antminer costs ~2000$ only... and you cannot play games on )

You have better chance waiting a gold cow falling in your garden!

[bridgman]

Unapproved again

[bridgman]

Now I only wished all the development would happen more open in the public. Sure, the code is open, there is a lot on freedesktop.org, in irc channels, etc. etc. but I wish the components would move to some platform like github like the ROC ones did. Issue reports, feedback, feature requests, commits, pull requests, the code itself, comments... all together at one place, detailed but clearly arranged. Also, a public roadmap would be nice to see what is actually being worked on, allowing to estimate a rough date, too.

We have also moved review/revision of patches etc.. from an internal ML to a public one at:

https://lists.freedesktop.org/mailman/listinfo/amd-gfx

With ROC we had the ability to put everything in one place because most of the projects were all new, ie we were not working in projects that already have infrastructure and conventions in place. ROC's kernel is currently out of tree but we're in the process of pushing that upstream as well.

That said, what we are doing with ROC at the moment is pushing snapshot releases to github, so I guess there's no reason why something similar couldn't be done with the graphics stack once the infrastructure is in place. We are hoping to leverage the tools we are building for the hybrid/pro stack for use with all-open as well at some point, so I think we are all looking in the same direction.

[haplo602]

Not comparison, but you have couple 1080p numbers here:

http://www.phoronix.com/scan.php?pag...ide-By-Side-GL

now that's a sorry excuse for 1080p tests ... not usable without a lot of back and forth comparisons ...

[ixxxo]

I'm using Ubuntu 16.04 with it and I haven't had any problems when running on DisplayPort, but I did have problems with HDMI, but it doesn't seem like we are having the same problem.

Hm, I am using HDMI actually, will try to get DP cable to test. Wat were your issues? By the way, currently running on amdgpu + padoka ppa, I can start games but performance is super low (like 1 FPS already in menu, tested 2 games).

EDIT: Seems it was OS-related issue, I installed Mint 18 Mate and no issue. Btw one more guy reported same issue with amdgpu pro + R9 390, so might be issue of that particular Cinnamon edition of Mint or cinnamon itself. No problem with HDMI by the way.

[juno]

@Michael: thanks for this elaborate test!
bridgman, agd5f, etc (the whole team): thanks for making this happen!
It's the greatest recent AMD launch by far, imho. Sure, there is more to do but the initial state of support is very, very nice.
AMD introduced the new way to go with the Linux stacks and delivered in time. I think we're looking at a great future for free, easy and high performing Linux graphics support.

Now I only wished all the development would happen more open in the public. Sure, the code is open, there is a lot on freedesktop.org, in irc channels, etc. etc. but I wish the components would move to some platform like github like the ROC ones did. Issue reports, feedback, feature requests, commits, pull requests, the code itself, comments... all together at one place, detailed but clearly arranged. Also, a public roadmap would be nice to see what is actually being worked on, allowing to estimate a rough date, too.
I think a more "open" manner might also attract more community devs.

[LinuxID10T]

Michael, can you post some more details how you got AMDGPU PRO working with RX 480? I tried today on Linux Mint 18 Cinnamon (beta so far), but after driver 16.30 installed successfully, I am not able to render desktop environment properly (no text, no icons). Interestingly enough, Steam app and its pop-ups work flawlessly.

I'm using Ubuntu 16.04 with it and I haven't had any problems when running on DisplayPort, but I did have problems with HDMI, but it doesn't seem like we are having the same problem.