AMD Radeon RX 480 On Linux

[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!

[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!

[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.

[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.

[pszilard]

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

Yeah, I know, that's why I asked. Could have just simply stated that miner benchmarks don't matter == BS, but I did not want to be an ass.

The new OpenCL hashcat is BTW a much more relevant benchmark. So is F@H. Or our code in GROMACS.

[bridgman]

@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.

I believe the OpenCL compiler path today is as follows....

OpenCL kernel code goes through clang/llvm with an HSAIL backend, then the resulting HSAIL goes through our proprietary shader compiler / finalizer to generate HW ISA.

Until recently only the OpenCL 2.0 paths went through HSAIL while lower levels of OpenCL went through AMDIL - I believe the latest driver builds use HSAIL all the time but will confirm. Also until recently we used a third party C++ front end rather than clang; will confirm that the current driver builds are actually using clang.

The ROC stack supports both HSAIL and direct-to-ISA (aka the "Lightning compiler") paths. I believe HSAIL is still the default for HCC at the moment. The lightning compiler uses the same clang front end and llvm framework but uses the amdgpu direct-to-ISA back end rather than the hsail back end + finalizer.

Depending on when we start releasing OpenCL-over-ROC it may still be using the HSAIL paths or may have moved to Lightning already.

[cde1]

Well it turns out the Radeon RX 480 I just received has a defective fan (off center and scratches against the case) and in any case does not output an image. Not going to buy a reference card again at launch (I don't blame Sapphire since they didn't design it).

[Kano]

You believe everything from PR it seems... for Linux CF is completely useless! In a week you can get a GTX 1060, much better choice for Linux gamers.

[Kano]

I see no reason to focus on OSS drivers for gaming. I would like to see vdpauinfo and Kodi/mpv test in case of HEVC Main 10 active. I would use the best possible driver for the purpose i want to use a card. This can be OSS in case of mainly HTPC use, some games might be better with OSS AMD drivers too, i just can not use AMDGPU with Kanotix yet (only AMDGPU-PRO should work). I see no reason to make a political statement for OSS drivers as many use it to play closed source games - so your system is not "clean" anyway. No Windows user ever cared that the drivers are closed source.

[puleglot]

I would like to see vdpauinfo and Kodi/mpv test in case of HEVC Main 10 active.

As was already pointed out earlier in this thread, HEVC Main 10 is not supported by VDPAU. It's an VDPAU API limitation. Would be nice to see vainfo output.