Quote from: Golku on November 23, 2016, 05:20:09 PM

Quote from: fasdorcas on November 23, 2016, 04:51:26 PM

Quote from: Heatspeed on November 23, 2016, 04:49:35 PM

Quote from: Claymore on November 23, 2016, 02:51:58 PM

Quote from: forzendiablo on November 23, 2016, 02:34:19 PM

i feel 280x the cards Claymore loves the most - will have 200 sols per card i nthe update

)

I like 390-390X the most - I'm going to reach 300H/s on stock clocks.
RX480 will show about 190-200 I think.
280X - about 200 or a bit more.

What Hashrate will a R9 Nano have on v8?
Is it even possible for a rx480 to get a hashrate above 200 H/s?
I'm trying to figure out whats the best investment for another rig..
Btw. good work!

Somebody analyses the hash rate of the RX 470. The limit is around the 170 H/s. So it will not be too high.

170 for a 470 how in the world are you going to achieve that without getting ridiculous high wattage?

Im hashing with my 470 at 150 with a decent wattage

nerdralph said

While my initial analysis was focused on the external GDDR5 bandwidth limits, current ZEC GPU mining software seems to be limited by the memory controller/core bus. On AMD GCN, each memory controller can xfer 64 bytes (1 cache line) per clock. In SA5, the ht_store function, in addition to adding to row counters, does 4 separate memory writes for most rounds (3 writes for the last couple rounds). All of these writes are either 4 or 8 bytes, so much less than 64 bytes per clock are being transferred to the L2 cache. A single thread (1 SIMD element) can transfer at most 16 bytes (dwordX4) in a single instruction. This means a modified ht_store thread could update a row slot in 2 clocks. If the update operation is split between 2 (or 4 or more) threads, one slot can be updated in one clock, since 2 threads can simultaneously write to different parts of the same 64-byte block. This would mean each row update operation could be done in 2 GPU core clock cycles; one for the counter update, and one for updating the row slot.

Even with those changes, my calculations indicate that a ZEC miner would be limited by the core clock, according to a ratio of approximately 5:6. In other words, when a Rx 470 has a memory clock of 1750Mhz, the core would need to be clocked at 1750 * 5/6 = 1458Mhz in order to achieve maximum performance.

If the row counters can be kept in LDS or GDS, the core:memory ratio required would be 1:2, thereby allowing full use of the external memory bandwidth. There is 64KB of LDS per CU, and the AMD GCN architecture docs indicate the LDS can be globally addressed; i.e. one CU can access the LDS of another CU. However the syntax of OpenCL does not permit the local memory of one work-group to be accessed by a different work-group. There is only 64KB of GDS shared by all CUs, and even if the row counters could be stored in such a small amount of memory, OpenCL does not have any concept of GDS.

This likely means writing a top performance ZEC miner for AMD is the domain of someone who codes in GCN assembler. Canis lupus?