AMD Vega Hardware Reviews

Thing is it doesn't really beat the 29MH/s @95W one can get from a GTX 1070.
No way of knowing how much power Vega uses on hashing. If leveraging packed math and ultimately bottlenecked by memory the power consumption could be extremely low. Puts the burden on HBM which is designed for lower power usage. Depending on the algorithm used, AMD would have had hashing instructions for SME designed to work transparently.
 
Thing is it doesn't really beat the 29MH/s @95W one can get from a GTX 1070.

Why not? Power really doesn't matter much compared to raw power. Power is super cheap vs how much you mine.

Lets even do a super high 30c/kw for power

100MH/s @ 300w will generate ~$121 and give 0.83 coins
29MH/s @ 95w will generate ~$33.60 and only give 0.24 coins


Thats underclocking a 1070 and over estimating the Vega GPU power as well. I was mining over 30MHs for little power on my Fury when I was mining a few months ago.

If Vega only uses 200w for 100MHs that is a gain of $143 per month!

Even @ 70c/kwh @ 300w Vega would pull in $35 per month which beats out that 1070... And no way would power cost that much or Vega use that much power.

Edit: Damn I think you just sold me on a Vega :p, probably last a good 2 months even with high power when difficulty spikes and assuming coin price doesn't go up (it would likely with a difficulty spike) it would half way pay itself off...
 
Thing is it doesn't really beat the 29MH/s @95W one can get from a GTX 1070.
70 MH/s @210W for the Vega 56 is slightly better per watt and it will be even better with undervolting, assuming that the rumored hash rate is correct (I am skeptical).

Sent from my SM-G928F using Tapatalk
 
Thing is it doesn't really beat the 29MH/s @95W one can get from a GTX 1070.
You're talking a 1070 optimized for mining.
We don't know what kind of mining perf/watt you can squeeze out of RX Vega. For all we know it can drop to 50W and barely lose any hashing. (Not likely, but hey)
 
We'll have to see. I know RX580s are far less efficient than 1070s at this point I built a rack of each and the RX580s consume nearly 600W more than the 1070s for a slightly lower hashrate. They run much hotter too. I run the 580 fans in the 90% range to keep <=60 C whereas I run 55% fans on the others and they don't break 45C. Guess we'll see. If they really do 100MH/s for 200W that'll be bad for gamers. Let's hope it's closer to 70MH/s @300W :)
 
You're talking a 1070 optimized for mining.
We don't know what kind of mining perf/watt you can squeeze out of RX Vega. For all we know it can drop to 50W and barely lose any hashing. (Not likely, but hey)
if amd comes out so confident about vega hashing capabilities id say that amd was mining for the past 6 months with vega's and they gonna resell them as new :p
 
70-100 is bullshit
We have some anonymous guy vs Claymore who made best miners for AMD
currently I see 35-36 MH/s ETH at stock clocks and huge speed for second coins. But it's too hot even at 1.0v for core and 0.9v for memory.
So 30MH@100W for 1070 vs 35MH@300W, not even funny
 
chavvdarrr, can you link to that post?
Does Claymore have an RX or was that an FE?
 
His dual mining is impressive. I get a tiny drop in ETH hashrate when enabling and a 300+ watt increase in consumption. Apparently there's no way to use that untapped computational resource for the primary blockchain work.

Thanks for the link.
 
If that's only one single card, it's more than impressive. With a 1080 (the „regular“ competition for Vega as it seems now), I'm getting less than half of that (11 MH/s ETH + 1800 MH/s DCR with dcred intensity set to 500 (-dcri 500).Edit: Didn't do dual-mining before, performance was not where it should be. correction: 12 MHS/s ETH and 2050 MH/s DCR, but still.
 
Last edited:
-dcri 500 is pretty huge bias and really killing your ETH hashrate. I'm finding 50 to be a better setting for me but I'm not prioritizing decred.
 
Yes, it is. I just tried to adjust settings to what claymore used:
claymore said:
BTW, at "-dcri 500" I get 4600MH/s DCR (at stock clocks) after some Vega-related improvements in assembler code (i.e. these improvements are not available for Polaris cards), now I'm working on SIA and PASC...
At "-dcri 100" I see 35MH/s ETH and 3500MH/s DCR.
If I set 1050MHz for memory (default is 945MHz), I get 40MH/s ETH.
-> https://bitcointalk.org/index.php?topic=1433925.msg20469546#msg20469546

With dcri 100, a 1080 with mem-OC is at 24,9/830 MH/s for ETH/DCR dual mining - especially the 2ndcoin is unbelievably strong with Vega.
 
Its not clear from his posts what cards he has, but given that AMD supposedly fixed their drivers for Vega,Fiji &Polaris (increasing ethereum speed with bigger DAGs) because of his input... I prefer to beleive him
https://bitcointalk.org/index.php?topic=1433925.msg20464462#msg20464462
He claims 40-41MH/s with memory overclock and no dual-mining (heat issue I guess)

It can only be with FE version, or it seems the Vega 64-56 seems acting differently. Power manangement have been fixed on them and it seems the 2x 4GB HBM bring less power than 2x 8GB.
( or fix thermal issue ).

I dont think he speak about support by the driver, look like he speak about the new version of the miner who have been updated with Vega support.

it is not clear if this driver is in the wild.. ( Note that i don't put much trust on this 70-100 ( seems a bit too huge )..

This said, the card have updated mining / hash optimization compared to Polaris ( offcial AMD slide )... Dont know if they are, was enabled in the FE version.

Anyway, it is just a rumor, yet.. time will tell.
 
Last edited:
Strange considering the use of HBM2 and the limited TFlops advantage over Fury. Maybe the first driver optimisation for Mining?
HBM2 is somewhat meaningless. The whole HBM is bad stems largely from a capacity issue. Fiji having lots of compute, bandwidth, and relatively low capacity.

Also driver seems to have been updated with different optimization, including for mining. ( Note that i dont put much trust on this 70-100 ( seems a bit too much huge )..
Driver aside, optimizing the actual algorithm would make more sense here. Get packed math enabled or use some of the new instructions and a performance increase isn't surprising. Vega would have significantly more cache, probably different VGPR arrangement, packed integers/hashing, and may or may not have had HBCC enabled. Assuming HBCC is even useful or practical for coin mining with all the risers. Some adjustments would seem necessary.
 
HBM2 is somewhat meaningless. The whole HBM is bad stems largely from a capacity issue. Fiji having lots of compute, bandwidth, and relatively low capacity.


Driver aside, optimizing the actual algorithm would make more sense here. Get packed math enabled or use some of the new instructions and a performance increase isn't surprising. Vega would have significantly more cache, probably different VGPR arrangement, packed integers/hashing, and may or may not have had HBCC enabled. Assuming HBCC is even useful or practical for coin mining with all the risers. Some adjustments would seem necessary.

Exactly and anyway mining on the FE was not make much sense ( price alone ) so i will not be surprised that it was not enabled for it.
 
HBM2 is somewhat meaningless. The whole HBM is bad stems largely from a capacity issue. Fiji having lots of compute, bandwidth, and relatively low capacity.
The impression I get is that in this context it is the diminishing returns versus compute and bandwidth noted for Ethereum in particular for GPUs using HBM and GDDR5X. Both Fury and the GTX 1080 saw reduced rates given their resource advantage over lesser products, whereas the GDDR5-based 1070 saw better results. I haven't seen a definitive analysis as to what caused that outcome, or how significant that difference still is.

The capacity doesn't seem to be strictly a problem, given the popularity of 4GB cards even in the era where Fury was considered something letdown, and Ethereum trying to adjust at various times so that it stays applicable to more GPU hardware.

Vega would have significantly more cache, probably different VGPR arrangement,
I'm not seeing a strong indication that VGPRs are changing that much in terms of what the software sees, how the VGPRs look from the die shot, or how AMD's slide on its SRAM customizations seemed to be more concerned about making the register files just be more efficient in terms of area, power, and delay.

Assuming HBCC is even useful or practical for coin mining with all the risers. Some adjustments would seem necessary.
It may depend on the cryptocurrency or mining algorithm, but outside of possibly secondary effects like better page handling or bandwidth utilization of on-board RAM, HBCC's ability to page large amounts of memory doesn't sound like it should help.
The reason for GPU-friendly cryptocurrencies is that they were adjusted to not be scalable for ASICs or esoteric accumulations of ALU or memory storage that might lead to concentrations of mining capability in specialized hardware or clusters.

The size for Ethereum is aligned with a more general amount of GPU RAM and leans on the specific abundance of local device bandwidth, and odds are if HBCC and its capacity play somehow had an outsized competitive difference they could tweak it further so that it didn't.
 
Exactly and anyway mining on the FE was not make much sense ( price alone ) so i will not be surprised that it was not enabled for it.
Oddly enough, if those upper end hash rates hold FE might be viable at that price. Given a cheaper alternative and supply, yeah RX would be a better choice.

I haven't seen a definitive analysis as to what caused that outcome, or how significant that difference still is.
I'm not seeing a strong indication that VGPRs are changing that much in terms of what the software sees, how the VGPRs look from the die shot, or how AMD's slide on its SRAM customizations seemed to be more concerned about making the register files just be more efficient in terms of area, power, and delay.
My take was that it had to do with how many waves were being launched. I haven't studied crypto in any detail so speculating there. That being the case, if Vega significantly increased VGPRs, accommodating far more active waves, it would be a concern. Not accounting for any changes to LDS mechanics or temporary registers (SIMD local LDS?) that may need some explicit coding to see gains with hashing algorithms. Also the possibility of packed math for the algorithms increasing the amount of waves in flight.

It may depend on the cryptocurrency or mining algorithm, but outside of possibly secondary effects like better page handling or bandwidth utilization of on-board RAM, HBCC's ability to page large amounts of memory doesn't sound like it should help.
I don't know enough about the access patterns to really judge the impact, just that it's possible. If accesses were grouped or following a parabolic/clustered distribution in their access pattern over time as opposed to completely random. Where HBCC could page in active areas and maintain a more even distribution and throughput. Again, speculating on that, but it could be a possibility that presents the card with an opportunity to sustain far more throughput. Programming that would be difficult if the algorithms followed a random, yet clustered access pattern, as it would be inherently unpredictable.
 
Oddly enough, if those upper end hash rates hold FE might be viable at that price. Given a cheaper alternative and supply, yeah RX would be a better choice.

.

Well completely pure speculation from me, but i was think it is quite possible that they have not enable it specially for this reason. limited supply.. ( and been able to put the gpus in the hands they was intended )
 
Back
Top