Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 650. (Read 5805546 times)

Or

--sched-stop `date -d "+6 hours" +%H:%M`

... since shares are random

And 6 hours for a 1GH/s is approximately 5029 shares

Suggestion: Would it be possible to maintain on the first page of this tread a list of all the AMD graphics cards with the optimum settings for cgminer?

It's kind of cumbersome to keep reading through all those pages (202) at the moment - so it would be nice to have this information in one central place.

Con, maybe we can talk about integrating global offset parameter support into CGMINER?

Take a short look at http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/clEnqueueNDRangeKernel.html and the global_work_offset parameter. All that has to be taken into consideration from the kernel-side is in DiaKGCN. OpenCL 1.1 detection is in your code, too, which is needed, but I can't do the other required changes without a compiler.

In short, the nonce-base is not supplied via the base parameter, if GOFFSET is enabled, but instead via the global_work_offset parameter and used via the global work-item ID in the kernel. This saves a few instructions and can give us a small boost.

Dia

Yeah. You can say that again.

I would have done it but sadly my router died on me and I am still trying to fix it ...

IMHO one needs to test just 2.1 against 2.4 and ranges from below 300 for memory and above 900 for core.

I would love to see an expanded version of this that goes down to 100 (or lower) memclock using latest version of cgminer, latest drivers, and SDK 2.1.

Anyone have any ideas how to automate a loop of cgminer.
I would imagine the easiest would be something like.

setup config file w/ shares: "5000", static memclock, static coreclock, worksize defined, vectors defined.

script
a) modifies config file to next parameter set to be tested (i.e. V2, W256, memclock = 180)
b) starts cgminer
c) cgminer stops after 5000 shares (and script detects it)
d) capture and save final avg hashrate, rejects, errors, etc.
e) goto a

I would be happy to run something like this on one of my rigs.   Once we get the complete result set for one core clock we could run it at another core speed.  Between 5870s & 5970s I figure coreclocks of 725 (5970 stock), 800, 825 (5870 stock), 850, 875, 900, 925, 950, 1000 (watercooled ) would be useful.

Doing it manually would be a nightmare but if someone can make some semi-automated tool I would be happy to leave it running on one of my rigs.  Once we get data for SDK 2.1 we could compare it to SDK 2.4, 2.5, 2.6.  It is possible that some parameters do better on different versions of SDK (as an example maybe SDK 2.1 is best w/ high work, low vectors, low memclock but SDK 2.5 is better at smaller  work, high vectors, "normalish" memclock, etc).

I still have some problems with that Git-stuff, but it's such a great tool, wow ... it would be nice to default diakgcn to -v 2 and it seems -w 256 is better for me by ~0,5 MH/s but I can live with the default being 128 ^^.

There is something unusual about it running diakgcn and the hashrate appears to be more unstable, rising and falling more so it takes a while to get a reasonable grasp for what the hashrate really is. Since you're running 2 vectors, it effectively makes the hashrate update half as often as running my poclbm kernel since I use no vectors. Either way, the hashrates are really close.

Sounds not too bad . I will try -w 128 and compare results on my machine ... will report back, which one is faster for me at default clocks and on Win7 x64. I'm happy now!

Dia

Indeed it is faster now, and with -v 2, it is fastest allow cgminer to choose worksize which is ends up being 128 - it queries the "preferred worksize" and divides that by number of vectors.

You are but 1 Mhash off my current poclbm kernel with that Diakgcn 716.5 versus ck-poclbm 717.5

Yes, please do, and if things go well, we can have a new default kernel for GCN

That's true for the most part when reordering kernel-arguments to be in line with usage of them in the code, but I think it's part of a clean code, don't you think so?

So you created a new DiaKGCN branch, will this last so I can switch my local repo to that one ?

Dia

Did you use the code from the latest commits, here on Windows it's definitely faster with -v 2.

-I 9 -k diakgcn -d 0 -v 1 -w 256: ~524 MH/s
-I 9 -k diakgcn -d 0 -v 2 -w 256: ~539 MH/s

Dia

And thank you for the code. Now what advantage is there to reordering the variables passed to the kernel? In commit d86a38d1e75090e1ffb9df9e68aa13b1c8dcf9ec you shuffled arguments which appear to be mostly cosmetic. Would that be right?

Tried it, much slower.

Did you use -v 2 with DiaKGCN for your test? I'm not sure why, but it has always been faster on Phoenix to use it with -v 2.

Dia

Should be Cypress, yes. Dunno, what would be the best WORKSIZE default though ...

Thanks for your help with integrating DiaKGCN Con!

Dia

Yeah, exactly. Just updated my post to reflect that too.

Yes I remember this old graph. It would appear to me that cgminer's defaults of v2 w128 are the most robust for all tunings unless the user goes out of his way to tweak things manually, in which case he'll be choosing his own settings, thanks.

Yeah, it's Cypress.

The best worksize really depends on the user correctly setting the ram clock; on the default (1GHz), it's best 64 or 128 with 4 vectors.

V2-W128 is the "safe" bet, since it's almost constant through ram speeds.

V2-W256 is always better than V2-W128 for ram speeds <~425MHz, because even on dips (bad gpu/mem ratio) it's always faster.

Gonna link again the graphic I like so much (from phatk thread)

Awesome to see this. I hope to look at this and adapt to my own project too.