Quote from: Rusguy on November 28, 2016, 03:21:49 PM

Quote from: bardacuda on November 25, 2016, 09:02:29 PM

Quote from: Jinx99 on November 25, 2016, 08:57:03 PM

Quote from: KrokoTill on November 25, 2016, 08:50:45 PM

On my 290 memory controller load is rarely over 60%. Big difference is that beside 290 memory bus being 2x wider, memory runs at 1250 MHz vs 2000 MHz on your 480. This means that you can do all possible tricks but no way can use that tight timings as on 290 at 1250 MHz or 390 at 1500 MHz. OK suppose that you reduce mem clock on 480 to 1500 or 1250 MHz to get the same timings but then you still do not get the speed that is possible with 2x wider bus.

This is not question of memory througput.
Reducing memclock almost twice affects only to 20% hashrate drop.
https://ip.bitcointalk.org/?u=http%3A%2F%2Fi.piccy.info%2Fi9%2Fce2e18589c91c75caab3b10a46a2c9f2%2F1480097808%2F34039%2F1051816%2Fmemdrop.png&t=571&c=zWfZWhuCJrGaPQ

Quote from: nerdralph on November 22, 2016, 08:15:08 PM

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?

Core speed has more of an effect on 480s but they are still limited by memory bandwidth.

I'm very funny that you even still protect 290,390 here is about the memory of 4xx

According to AMD According to a CU efficiency increased by 15% compared to the Radeon R9 290. When processing tessellation in conjunction with heavy duty AA efficiency gains can be double or even triple. Supported data compression, thus improving memory bandwidth. In particular, supported by Delta Color compression algorithm that allows you to encode the color difference. On this technique we described in the description of the architecture NVIDIA Pascal. AMD has such compression is maintained including the Radeon Fury X, but the effectiveness of the algorithms at Polaris 10 above. With this increase in the efficiency of a data chip content bus word length of 256 bits. The Radeon RX 480 uses GDDR5 memory chips with an effective rate of communication 8 GHz.

And for that AMD has introduced new regulations of memory !!! such as FP16 and 16 Int.

Which I think Claymore's does not use, for this reason, the new data on the time of top 480 does not operate at full capacity. And at the same time using the old manual of memory with which he revived the old 7xxx to work at such speeds

And compared to the 7xxx, 290 and 390 may be given even greater speed, including 480 if you use the new instructions of memory that only support new models 290-390-480, though only suffer 7xxx model that greatly impact on mining in overall, since the data pattern immediately lose their significance in mining

http://i11.pixs.ru/storage/1/6/0/03amdradeo_6383058_24215160.png

I'm not "protecting" anything. I'm simply explaining why the Hawaii cards are faster and will remain faster than Ellesmere given that they have +50% higher memory bandwidth and this algo relies on memory bandwidth, and this has been reinforced by the devs that code these miners.

Quote from: Claymore on November 23, 2016, 03:52:27 PM

Memory bandwidth:

RX480: 256 GB/s
390X: 384 GB/s

ZEC uses a lot of memory operations. Do you still think that RX480 can work as fast as 390X?

I'm just letting you guys know so ppl stop whining in here that Claymore is somehow intentionally gimping the RX cards. Not only does he have no incentive to do that, he has a big incentive to do exactly the opposite. Otherwise, there's a large chance that people with RX cards are going to switch to Optiminer or ETH. In the case of Optiminer he gets no fees at all, and in the case of ETH he gets a much lower fee and that's only if they use his miner...which they probably won't because the no-fee miners like Genoil's are on par with his.

The fact that you quote AMD marketing stuff about color compression just shows that you are grasping at straws and wishing upon stars. Any speedup by these tweaks is only for changes in pixel colors in gaming scenarios, not compute tasks. You have to look at the "uncompressible data" part of the graph and you see that RX 480 gets no speedup due to delta color compression algos. Same thing goes for tesselation and AA optimizations in the compute units.

You also can't draw conclusions by underclocking the memory unless you use the same memory straps for every frequency...otherwise, every 125 or 250MHz drop the timings tighten, so a lot of the loss in bandwidth is made up in lower latency.