Pages:
Author

Topic: [AMD] New AMD RX Graphics Cards of 2019 - RX 5700 / XT, RX 600 - page 9. (Read 23318 times)

legendary
Activity: 2828
Merit: 1497
Join the world-leading crypto sportsbook NOW!
Can someone share a ProgPOW benchmark?
With the upcoming mining algorithm of progpow being released in the release of berlin imminent I would say this is important to know too.
Before forking over alot of money for a card and it only getting half the hashrate after the algo changes over in sometime in early 2020.

It is not wise to spend money right now when the future is not very clear.They have been saying to change to ProgPOW from sometime but they are hesitant to change.I think we need a wait and see approach to the changes,the cards perform well though in Cryptonight algorithm so if you are looking for long term usage you can go ahead and buy these cards.
Yeah I would agree with you there. I was just checking the dag file size for mining ethereum and it is at 3.23gb so anything below 8gb wont be able to mine the current algorithm when it reaches the 4 gb size limit.
Maybe mining another algorithm such as cryptonight you recommended would be a better option for the longevity of these cards thinking of future proofing the equipment you are purchasing now.
Best thing would be to wait to see where it all goes for the ethereum algo for now.

At this point why would anybody buy a rx 5700XT over a regular 5700 if they almost produce the same hashrate?

There has been someone I was watching on a youtube video which mentioned they were able to flash a 5700 to 5700xt and it worked fine for mining ethash. After the flashing it had all the same memory clocks as an xt version after checking them compared to before and after.
So it worked! Smiley
member
Activity: 449
Merit: 24
At this point why would anybody buy a rx 5700XT over a regular 5700 if they almost produce the same hashrate?

Only reason would be if the RX can mine other coins, might be a better at other algos.  The XT can get 77 on vert coin.
member
Activity: 180
Merit: 10
So basically we RX 5700XT users are stuck with ETHASH by Claymore now.
Using PhoenixMiner, somehow one of my two RX 5700 will crap out after sometimes and the one that is still mining will still be showing fully loaded after mining is stopped.

I have three XFX 5700XT cards and mining with PhoenixMiner 4.6c
No problems here. Hashing at ~52 MH/s each.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -mode 1 -clKernel 1 -clNew 1

good for you. Maybe because I force copy PhoenixMiner 4.6c latest exe into nicehash miner plugin folder, it's not stable.

Did you try running it without Nicehash?

Personally, I don't use Nicehash, I might might on their pool if it's more profitable but I don't use their program. For profit switching I use Awesome Miner.
jr. member
Activity: 199
Merit: 1
At this point why would anybody buy a rx 5700XT over a regular 5700 if they almost produce the same hashrate?
jr. member
Activity: 46
Merit: 4
So basically we RX 5700XT users are stuck with ETHASH by Claymore now.
Using PhoenixMiner, somehow one of my two RX 5700 will crap out after sometimes and the one that is still mining will still be showing fully loaded after mining is stopped.

I have three XFX 5700XT cards and mining with PhoenixMiner 4.6c
No problems here. Hashing at ~52 MH/s each.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -mode 1 -clKernel 1 -clNew 1

good for you. Maybe because I force copy PhoenixMiner 4.6c latest exe into nicehash miner plugin folder, it's not stable.
member
Activity: 180
Merit: 10
So basically we RX 5700XT users are stuck with ETHASH by Claymore now.
Using PhoenixMiner, somehow one of my two RX 5700 will crap out after sometimes and the one that is still mining will still be showing fully loaded after mining is stopped.

I have three XFX 5700XT cards and mining with PhoenixMiner 4.6c
No problems here. Hashing at ~52 MH/s each.

-tt 58 -cvddc 750 -cclock 1300 -fanmin 0 -mclock 900 -amd -mode 1 -clKernel 1 -clNew 1
jr. member
Activity: 46
Merit: 4
So basically we RX 5700XT users are stuck with ETHASH by Claymore now.
Using PhoenixMiner, somehow one of my two RX 5700 will crap out after sometimes and the one that is still mining will still be showing fully loaded after mining is stopped.
full member
Activity: 208
Merit: 117
Just covered a quick overview of two streams this past weekend on a 8x Sapphire 5700 XT Build. Watch the 7min recap here: https://youtu.be/hCA603-7C1U

As for the AMD 5700/XT support, the New Linux Kernel looks like it has Navi Support https://www.omgubuntu.co.uk/2019/09/linux-5-3-kernel-release-features
member
Activity: 79
Merit: 36
HODL. Patience.
Has anyone succeeded at getting these cards to work on Linux? Mine won't even fart.
legendary
Activity: 3136
Merit: 1233
Bitcoin Casino Est. 2013
Can someone share a ProgPOW benchmark?
With the upcoming mining algorithm of progpow being released in the release of berlin imminent I would say this is important to know too.
Before forking over alot of money for a card and it only getting half the hashrate after the algo changes over in sometime in early 2020.

It is not wise to spend money right now when the future is not very clear.They have been saying to change to ProgPOW from sometime but they are hesitant to change.I think we need a wait and see approach to the changes,the cards perform well though in Cryptonight algorithm so if you are looking for long term usage you can go ahead and buy these cards.
member
Activity: 180
Merit: 10
There is 19.9.2, any increase in the hashrate?

Nothing for me. I have three and there's no apparent difference.
legendary
Activity: 2828
Merit: 1497
Join the world-leading crypto sportsbook NOW!
Can someone share a ProgPOW benchmark?
With the upcoming mining algorithm of progpow being released in the release of berlin imminent I would say this is important to know too.
Before forking over alot of money for a card and it only getting half the hashrate after the algo changes over in sometime in early 2020.
member
Activity: 221
Merit: 12
There is 19.9.2, any increase in the hashrate?
newbie
Activity: 9
Merit: 0
whose mission will it be to use the 5700's 40 compute units?  mining software?
sr. member
Activity: 703
Merit: 272
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 Sad. 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.  Grin Grin
member
Activity: 658
Merit: 86
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 Sad. For the algos you mentioned, I think we'll start with things like MTP and x16r.
newbie
Activity: 11
Merit: 0

What about the other algos you do such as mtp, lyra2v3, cuckatoo31 and cuckarood29?
https://m.twitch.tv/videos/458679885
sr. member
Activity: 703
Merit: 272
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?
member
Activity: 658
Merit: 86
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.
Pages:
Jump to: