[AMD] New AMD RX Graphics Cards of 2019 - RX 5700 / XT, RX 600

[lexele]

in claymore's thread a user reported 51Mh/s ETH

[jstefanop]

Currently running 54 MH, haven't started messing with timings yet

Also claymore is still running this as old GCN code, he hasn't updated to Wave32 which should significantly reduce core load needed and reduce power to under 100 watts.

[szabka81]

Hi!
What is the miner name??

[rickwagner50]

I am getting 53.8 Mh/s with some brief tuning in Wattman with driver 19.9.1 and Windows 10 Pro.  This is on an RX 5700 blower style GPU.  Using Claymore v15.0 to mine Ethereum.

After a few failed attempts and reboots, I am now stable with memory overclocked to 950, core clock is running between 1700 and 1740 Mhz at 940volts.  Temps are low 60's with fan running at 2400rpm (not loud at all).  It is pulling 180 watts at the wall, however.  Need to work on that!  No setting in Wattman to reduce memory volts, only core volts are available.  Still, not a bad start!

UPDATE> reducing the core clock down to high 1500's with core volts at 870 the watts at the wall are down to 160, temps are down, fan speed slower and it still mines at 53.5 Mh/s

NOTE> Any change to core clock during mining results in an instant freeze and reboot is required.  Other changes in Wattman do not seem to have the same result.  Not a fan of Wattman

[Claymore]

Currently running 54 MH, haven't started messing with timings yet

Also claymore is still running this as old GCN code, he hasn't updated to Wave32 which should significantly reduce core load needed and reduce power to under 100 watts.

I do use wave32 mode. During tests I tried wave64 as well, both showed same speed.

[Eliovp]

I'll release a new version of AMD Memtweak XL later today with latest driver support (Strap injection support for latest driver)
So you can play around on your Navi card

Cheers!


Edit: Here

[Kasma7]

Hello.
I am a newbie and thinking of starting mining with these cards and need the help of the community.
Are the common PCI risers adequate for mining with these cards? Can I also use my asrock H110 mobo?

Thanks in advance.

[CS9SG]

Claymore v15
Mining ETC on ethermine EU server
RX5700 @ 49.75Mh/s

Xmrig AMD
Supportxmr
XMR
RX5700 @ 1.1KHh/s

[vuli1]

I'll release a new version of AMD Memtweak XL later today with latest driver support (Strap injection support for latest driver)
So you can play around on your Navi card

Cheers!


Edit: Here

strap injecting, thats soundsinteresting. 

[CS9SG]

Claymore v15
Mining ETC on ethermine EU server
RX5700 @ 49.75Mh/s

Xmrig AMD
Supportxmr
XMR
RX5700 @ 1.1KHh/s

12 hours trend of Rx5700 mining ETC
https://imgur.com/a/z9P4o9T

[fenomenyaa]

Anyone didn't try new driver on cnr?interesting that noone still don'tshare....

[Grim]

Can someone share a ProgPOW benchmark?

[rickwagner50]

Anyone didn't try new driver on cnr?interesting that noone still don'tshare....

I was able to get just over 1100 h/s in monero using XMR-STAK.  TRM didn't even recognize the GPU.  Not a great result for such an advanced GPU in my opinion.  I'll stick with ETH for now.  Would be nice if we could tweak the memory timings - that would certainly help on all mining.

[BenjaminWegener]

Can someone share a ProgPOW benchmark?

tested 2 miner on windows, no opencldevice found

[proffe14]

Need more tests for cards RX 5700/XT

[kerney666]

Anyone didn't try new driver on cnr?interesting that noone still don'tshare....

I was able to get just over 1100 h/s in monero using XMR-STAK.  TRM didn't even recognize the GPU.  Not a great result for such an advanced GPU in my opinion.  I'll stick with ETH for now.  Would be nice if we could tweak the memory timings - that would certainly help on all mining.

No, we haven't ported our (TRM) asm kernels for CN (and variants) to Navi, it's a pretty big effort, and toolchain support is not there yet. I'm not even sure we'll port the kernels given that we predict a shit hashrate, much like the one you're getting with xmr-stak. The reason is the switch to 128 byte L2 cachelines in the Navi architecture. Modern CN variants (CNv8, CN/r) use 64 bytes, older variants use 16 bytes whenever they touch mem. AMD GCN used 64 bytes cachelines, matching modern CN variants read/write patterns - no overhead.

So, what happens with CN for Navi is that for every mem access, you start by reading 64 bytes, but the mem controller on the Navi card actually reads 128 bytes since it always must pull a full cacheline into the L2 cache. This effectively doubles the consumed mem bandwidth, and you see a hashrate matching a pimped 580 rather than a Vega 56/64. In any case, crap CN hashrate compared to Vegas is the result.

For ethash, you always load 128 byte chunks anyway, matching the new L2 cacheline size, so no problem there.

[alucard20724]

Anyone didn't try new driver on cnr?interesting that noone still don'tshare....

I was able to get just over 1100 h/s in monero using XMR-STAK.  TRM didn't even recognize the GPU.  Not a great result for such an advanced GPU in my opinion.  I'll stick with ETH for now.  Would be nice if we could tweak the memory timings - that would certainly help on all mining.

No, we haven't ported our (TRM) asm kernels for CN (and variants) to Navi, it's a pretty big effort, and toolchain support is not there yet. I'm not even sure we'll port the kernels given that we predict a shit hashrate, much like the one you're getting with xmr-stak. The reason is the switch to 128 byte L2 cachelines in the Navi architecture. Modern CN variants (CNv8, CN/r) use 64 bytes, older variants use 16 bytes whenever they touch mem. AMD GCN used 64 bytes cachelines, matching modern CN variants read/write patterns - no overhead.

So, what happens with CN for Navi is that for every mem access, you start by reading 64 bytes, but the mem controller on the Navi card actually reads 128 bytes since it always must pull a full cacheline into the L2 cache. This effectively doubles the consumed mem bandwidth, and you see a hashrate matching a pimped 580 rather than a Vega 56/64. In any case, crap CN hashrate compared to Vegas is the result.

For ethash, you always load 128 byte chunks anyway, matching the new L2 cacheline size, so no problem there.

What about the other algos you do such as mtp, lyra2v3, cuckatoo31 and cuckarood29?

[BenjaminWegener]

What about the other algos you do such as mtp, lyra2v3, cuckatoo31 and cuckarood29?

https://m.twitch.tv/videos/458679885

[kerney666]

Anyone didn't try new driver on cnr?interesting that noone still don'tshare....

I was able to get just over 1100 h/s in monero using XMR-STAK.  TRM didn't even recognize the GPU.  Not a great result for such an advanced GPU in my opinion.  I'll stick with ETH for now.  Would be nice if we could tweak the memory timings - that would certainly help on all mining.

No, we haven't ported our (TRM) asm kernels for CN (and variants) to Navi, it's a pretty big effort, and toolchain support is not there yet. I'm not even sure we'll port the kernels given that we predict a shit hashrate, much like the one you're getting with xmr-stak. The reason is the switch to 128 byte L2 cachelines in the Navi architecture. Modern CN variants (CNv8, CN/r) use 64 bytes, older variants use 16 bytes whenever they touch mem. AMD GCN used 64 bytes cachelines, matching modern CN variants read/write patterns - no overhead.

So, what happens with CN for Navi is that for every mem access, you start by reading 64 bytes, but the mem controller on the Navi card actually reads 128 bytes since it always must pull a full cacheline into the L2 cache. This effectively doubles the consumed mem bandwidth, and you see a hashrate matching a pimped 580 rather than a Vega 56/64. In any case, crap CN hashrate compared to Vegas is the result.

For ethash, you always load 128 byte chunks anyway, matching the new L2 cacheline size, so no problem there.

What about the other algos you do such as mtp, lyra2v3, cuckatoo31 and cuckarood29?

We'll start porting properly as soon as the tools we use as a base for our build system are available for Navi, unfortunately for us and all users the progress is slow on that front . For the algos you mentioned, I think we'll start with things like MTP and x16r.

[alucard20724]

Anyone didn't try new driver on cnr?interesting that noone still don'tshare....

I was able to get just over 1100 h/s in monero using XMR-STAK.  TRM didn't even recognize the GPU.  Not a great result for such an advanced GPU in my opinion.  I'll stick with ETH for now.  Would be nice if we could tweak the memory timings - that would certainly help on all mining.

No, we haven't ported our (TRM) asm kernels for CN (and variants) to Navi, it's a pretty big effort, and toolchain support is not there yet. I'm not even sure we'll port the kernels given that we predict a shit hashrate, much like the one you're getting with xmr-stak. The reason is the switch to 128 byte L2 cachelines in the Navi architecture. Modern CN variants (CNv8, CN/r) use 64 bytes, older variants use 16 bytes whenever they touch mem. AMD GCN used 64 bytes cachelines, matching modern CN variants read/write patterns - no overhead.

So, what happens with CN for Navi is that for every mem access, you start by reading 64 bytes, but the mem controller on the Navi card actually reads 128 bytes since it always must pull a full cacheline into the L2 cache. This effectively doubles the consumed mem bandwidth, and you see a hashrate matching a pimped 580 rather than a Vega 56/64. In any case, crap CN hashrate compared to Vegas is the result.

For ethash, you always load 128 byte chunks anyway, matching the new L2 cacheline size, so no problem there.

What about the other algos you do such as mtp, lyra2v3, cuckatoo31 and cuckarood29?

We'll start porting properly as soon as the tools we use as a base for our build system are available for Navi, unfortunately for us and all users the progress is slow on that front . For the algos you mentioned, I think we'll start with things like MTP and x16r.

Thanks for the update.  I'm looking forward to it.