Gateless Gate Sharp 1.3.8: 30Mh/s (Ethash) on RX 480!

[citronick]

Great work! Any improvements about XMR in pre3?

Hi, it's allready the fastest XMR miner (at least that I found out) and it's open source, so what's the point being even faster? As everybody will be faster and you will not get more XMR.

While on ZEC, the faster miners are closed source with devfee, that's why Zawawa's miner is awaited.

You're not right. Fastest XMR miner at this moment is Claymore CryptoNote 9.7.
Even with 2% fee it gives about 5-10% more speed on 280X.

on my 290x GG is 15% faster, on my RX470 not much faster but it's faster.

But on 280X Claymore is faster. Thats mean that GG is not fastest miner at this moment. Maybe author optimizes something else and it became the best )

Claymore v9.7 is best for non-RX cards (290s/390s/R9 cards). He needs to further optimise the miner for RX/Polaris (long time overdue).

For RX cards, Wolf's XMR miner and sgminer-gm, sgminer-gg will be a better and more stable miner.

[Sam123]

Great work! Any improvements about XMR in pre3?

Hi, it's allready the fastest XMR miner (at least that I found out) and it's open source, so what's the point being even faster? As everybody will be faster and you will not get more XMR.

While on ZEC, the faster miners are closed source with devfee, that's why Zawawa's miner is awaited.

You're not right. Fastest XMR miner at this moment is Claymore CryptoNote 9.7.
Even with 2% fee it gives about 5-10% more speed on 280X.

on my 290x GG is 15% faster, on my RX470 not much faster but it's faster.

But on 280X Claymore is faster. Thats mean that GG is not fastest miner at this moment. Maybe author optimizes something else and it became the best )

Claymore v9.7 is best for non-RX cards (290s/390s/R9 cards). He needs to further optimise the miner for RX/Polaris (long time overdue).

For RX cards, Wolf's XMR miner and sgminer-gm, sgminer-gg will be a better and more stable miner.

Can you please share the link for the Wolf XMR miner (RX480 cards)
Thanks

[laik2]

Great work! Any improvements about XMR in pre3?

Hi, it's allready the fastest XMR miner (at least that I found out) and it's open source, so what's the point being even faster? As everybody will be faster and you will not get more XMR.

While on ZEC, the faster miners are closed source with devfee, that's why Zawawa's miner is awaited.

You're not right. Fastest XMR miner at this moment is Claymore CryptoNote 9.7.
Even with 2% fee it gives about 5-10% more speed on 280X.

on my 290x GG is 15% faster, on my RX470 not much faster but it's faster.

But on 280X Claymore is faster. Thats mean that GG is not fastest miner at this moment. Maybe author optimizes something else and it became the best )

It's the fastest open source miner, I repeat - OPEN SOURCE !
As of your statement that Claymore's CryptoNote miner is the fastest - your are absolutely wrong, sgminer-gm/gg are still faster

[zawawa]

I am not going to join this "Who got the fastest miner?" discussion.
Project GG's slogan is: "The best miner should be free."
I mean, Bitcoin founder Satoshi Nakamoto was so generous.
Why shouldn't we?

[Ursul0]

getting closer...


EDIT: actually two of the cards just went SICK after 5 minutes, while Claymore works for days with no issues

[nerdralph]

Using SLC or GLC memory read/write may also give a small performance boost.

Could you elaborate on this? I recall you said Wolf was using them for his private miner, but I am not entirely sure how to use SLC/GLC bits for performance enhancements.

The SLC (System Level Coherence) bit forces bypassing the L1 cache, and GLC (Global Level Coherence) forces bypassing the L2.  For ETH mining, which is 100% memory reads, I think SLC gave a performance improvement, but GLC did not.  The results weren't completely intuitive, so you'll probably have to do some experimenting.  I also suspect you may get different results from different GCN versions.  Pitcairn and Tahiti seem to have a brain-dead cache controller that gets slower as the working set gets much over 1GB.  Therefore I think GLC read/write may have a more significant impact for them vs Tonga (or even Hawaii).

[zawawa]

EDIT: actually two of the cards just went SICK after 5 minutes, while Claymore works for days with no issues

That must be a hardware issue. Different miners tend to expose different hardware problems.
Also, for optimal performance with Ellesmere, you need to run the miner on Linux for now.
I think the only real technical advantage Claymore has over me is that he figured out how to access the entire GDS both on Windows and Linux.

[zawawa]

Using SLC or GLC memory read/write may also give a small performance boost.

Could you elaborate on this? I recall you said Wolf was using them for his private miner, but I am not entirely sure how to use SLC/GLC bits for performance enhancements.

The SLC (System Level Coherence) bit forces bypassing the L1 cache, and GLC (Global Level Coherence) forces bypassing the L2.  For ETH mining, which is 100% memory reads, I think SLC gave a performance improvement, but GLC did not.  The results weren't completely intuitive, so you'll probably have to do some experimenting.  I also suspect you may get different results from different GCN versions.  Pitcairn and Tahiti seem to have a brain-dead cache controller that gets slower as the working set gets much over 1GB.  Therefore I think GLC read/write may have a more significant impact for them vs Tonga (or even Hawaii).

Thanks for the clarification. Yeah, these features definitely make more sense for access to ETH's huge DAG. Let's see what I can do with them for ZEC...

[zawawa]

It seems like it is possible to access PCIe devices directly in the user space on Windows, too:

https://msdn.microsoft.com/windows/hardware/drivers/wdf/comparing-umdf-2-0-functionality-to-kmdf

Well, there is something to learn every day...

[zawawa]

Let me see if this works...

https://github.com/rumpkernel/wiki/wiki/Howto:-Accessing-PCI-devices-from-userspace

[zawawa]

This is the portion of the Linux kernel responsible for GDS-related parameters for compute kernels:

Code:

		if (gds) {
			p->job->gds_base = amdgpu_bo_gpu_offset(gds);
			p->job->gds_size = amdgpu_bo_size(gds);
		}

https://github.com/torvalds/linux/blob/ef96152e6a36e0510387cb174178b7982c1ae879/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c

I should be able to change them by modifying the kernel source code.
I love free software!

[zawawa]

I just patched the Linux kernel as an experiment:

Code:

		if (1 /*gds*/) {
			p->job->gds_base = 0; // amdgpu_bo_gpu_offset(gds);
			p->job->gds_size = 65536; // amdgpu_bo_size(gds);
		}

This may actually work...

[john1010]

How many hash it will produce on ethereum usage? thanks

[zawawa]

How many hash it will produce on ethereum usage? thanks

About 10% lower than Claymore's. You should try it yourself.

[zawawa]

THE KERNEL PATCH IS WORKING!! WHOO HOO!!!!

[zawawa]

Well, it turned out that multithreading wasn't working, so I'm still working on the kernel patch.
The miner is running about 15% faster with a single thread, so it's very promising.
I should be able to get rid of the patch entirely by hooking system calls to the driver later.
This is no easy stuff!

[zawawa]

It seems that the real maximum size of GDS segments for RX 480 is 16KB.
It's a little disappointing, but still much better than 4KB without the kernel patch.
This number is also consistent with nertralph's report that Optiminer runs four CPU threads per GPU as GDS utilization can be maximized this way.
Now let me fix the kernel patch one more time...

[doktor83]

so good to see how much you love doing this zawawa

[nerdralph]

It seems that the real maximum size of GDS segments for RX 480 is 16KB.
It's a little disappointing, but still much better than 4KB without the kernel patch.
This number is also consistent with nertralph's report that Optiminer runs four CPU threads per GPU as GDS utilization can be maximized this way.
Now let me fix the kernel patch one more time...

Or maybe Optiminer runs just 2 instances of the kernel and uses only half of the GDS.  It's possible (I'd even say probable) the benefits of using a full 64KB is offset by slower GDS access caused by contention with 4 instances of the kernel running.

[jstefanop]

It seems that the real maximum size of GDS segments for RX 480 is 16KB.
It's a little disappointing, but still much better than 4KB without the kernel patch.
This number is also consistent with nertralph's report that Optiminer runs four CPU threads per GPU as GDS utilization can be maximized this way.
Now let me fix the kernel patch one more time...

Or maybe Optiminer runs just 2 instances of the kernel and uses only half of the GDS.  It's possible (I'd even say probable) the benefits of using a full 64KB is offset by slower GDS access caused by contention with 4 instances of the kernel running.

Pretty sure both optiminer and claymore running two kernel threads.