OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[gigica viteazu`]

still no 1.5.3 version for windows ?

[miscreanity]

The purple line is one rig running the current head of the git tree, with ah42's changes in.
(that's 1.5 MH/s more than stock 1.5.3).

I don't have a chart (curious if you'd share your method for generating the graph from data), but that's about what I've seen with the latest git as well: ~1.5Mh/s increase with Linux 2.6.38, 11.6/2.4 on 69xx cards. Run time so far of about 1 hour.

The really nice bit is that the rejected rate has dropped below 1% so far from about 1.6% on average. If that can be maintained with Dia's phatk modifications, it'll be very impressive.

[miscreanity]

It's a rather messy setup of perl scripts and web servers:

Thanks for the outline. Flexible and nice to get Mh/s stats. More than I'd need with just accepted/rejected shares, though.

[tigereye]

I am running the exact same thing, and I don't see your problem.

Code:

[2011-08-09 23:57:10] Error: Getting program info CL_PROGRAM_BINARY_SIZES. (clGetPlatformInfo)
[2011-08-09 23:57:10] Failed to init GPU thread 0
[2011-08-09 23:57:15] Error: Getting program info CL_PROGRAM_BINARY_SIZES. (clGetPlatformInfo)
[2011-08-09 23:57:15] Failed to init GPU thread 0

When trying to get it to compile I had to first APT-GET a few packages including pkg-config, libcurl4-gnutls-dev, curl, libncurses5-dev and autoconf.

In my opinion, you're barking up the wrong tree: this looks like
cgminer does not manage to detect your GPU. Have you verified
that your GPU is visible/available/working using other utilities ?
(aticonfig comes to mind).

Another possibility: did you do the following :

Code:

cd /; tar zxpvf /opt/AMD-APP-SDK-v2.4-lnx64/icd-registration.tgz

Without the above, things are very likely to behave according to
what you describe.

Thanks for the suggestions, but unfortunately none of them work.

cgminer can detect the GPUs in SOME capacity because when I do a "cgminer --ndevs" it lists 8, which is the number of GPU devices I have installed in the system.

The GPUs are being used successfully by phoenix miner. I want to switch over to cgminer.
Of all of my rigs, this is the only one that is reporting this problem. The other rigs have identical motherboards/GPUs and are running the same version of linuxcoin. I've successfully switched them over to cgminer, but I can't get this one rig to work.

Furthermore, the AMD icd-registration.tgz has been extracted using the commands you recommended.
I just did it again to see if it'd change the results, but I am still getting the same errors about the clPlatformInfo call.

Any other ideas?

If worse comes to worst, I may just clone the disk from one of the other rigs... but that's a huge pain!

Thanks in advance for any further help any of you can provide...

[oppiet30]

Is there a reason that the $ appears in this line?

CPU 0: [1.$ / 0.9 Mh/s] [Q:56  A:0  R:1  HW:0  E:0%  U:0.00/m]

http://oppie.homelinux.com/screenshot.png

This is using cgminer 1.5.3 as seen in the screenshot.

[-ck]

It's not Diapolo's last changes I want in cgminer, but rather phateus's latest (phatk 2.2).
This runs at 371 MH/s on my 5970s

And now that I look at the code ... the phatk kernel has an API that is not compatible
with what cgminer calls (phatk OpenCL code requires pre-computed values that aren't
provided by cgminer)

I guess the approach phoenix took is the best: via the __init__.py module it lets a
kernel precompute whatever it wants before it calls the OpenCL code ... we would
need something similar for cgminer (i.e. a combination of a .cl kernel and some
init code). Unfortunately, that's kind of hard to pull off in C (short of adding a LUA
interpreter to cgminer). Tough.

I was mistakenly under the impression your changes incorporated everything from the latest kernels. Perhaps I may have to roll them all back and start porting it all myself. Darn. 

[-ck]

Sorry I mixed you up with ah42. I'm quite aware of the changes required to make it work though, thanks.

[ah42]

Current 110810 kernel on git has 1368 ALU OPs for 58XX and 1696 for 69XX, that's neither phatk 2.2 nor my latest result (which is 1364 / 1688), but a bit faster than the last official CGMINER kernel. I mailed my latest version to Con for review .

The added __attribute__((vec_type_hint(u))) is unknown to the compiler and throws a warning, but IS mentioned in the OpenCL 1.1 manual ... strange.

Dia

Correct, it's not 2.2, nor your most recent. It was an honest attempt at integrating *both* of them, but I think now that  I missed a few things.

I had noticed the Kernel Analyzer threw an error about vec_type_hint, but it compiles without issue on linux. I don't have native windows (only virtualized) to test anything there. In testing, I was unsure as to whether vec_type_hint made an improvement, but I was certain that it wasn't the opposite.

[ah42]

I was mistakenly under the impression your changes incorporated everything from the latest kernels. Perhaps I may have to roll them all back and start porting it all myself. Darn. 

I had attempted to, however, I was trying to incorportate both phatk2.2 and diapolo's versions, since in my attempts, i was not able to integrate either of them alone to get cgminer to work as well as either of those versions were, running standalone.

I also realised late lastnight that I might have missed a few things that could have changed things, but my VirtualBox windows .vdi crapped out on me, so I'm unable to utilize the Kernel Analyzer right now.

One thing I definitely want from Diapolo's most recent work is the new output method. Not only is it faster, but it seems to subjectively give a *much* higher Efficiency/Utility. (Not tested over a long enough timespan to say objectively)

[-ck]

I would say you need to attribute ZERO value to any perceived changed to utility and efficiency. It's entirely network dependent, so please do not place any value on it. When pools with 3Thash or more can go from -40 to +10% efficiency, it's impossible to use those to determine performance.

[-ck]

One thing I definitely want from Diapolo's most recent work is the new output method.

It's interesting that it should be faster

a = (b == c);
is the same as
if (b == c) a = 1; else a = 0;

as far as code is concerned and ends up being compiled into the same thing in c.

Perhaps it's a weakness in the opencl compiler, or maybe it's just the jump path is inefficient since there are multiple statements in the if {} loop.

Anyway I've merged it for what it's worth, and updated poclbm accordingly as well.

(EDIT: By the way, I'm not seeing any improvement).

[Diapolo]

One thing I definitely want from Diapolo's most recent work is the new output method.

It's interesting that it should be faster

a = (b == c);
is the same as
if (b == c) a = 1; else a = 0;

as far as code is concerned and ends up being compiled into the same thing in c.

Perhaps it's a weakness in the opencl compiler, or maybe it's just the jump path is inefficient since there are multiple statements in the if {} loop.

Anyway I've merged it for what it's worth, and updated poclbm accordingly as well.

(EDIT: By the way, I'm not seeing any improvement).

I tried to avoid control flow (which has very high costs on GPUs) and this method was mentioned in an AMD APP SDK document.

Dia

[-ck]

Unfortunately, on my 6970s it is actually appearing to be slower   I may have to revert this change.

edit: On my 6770 it's clearly faster and clearly slower on the 6970s... now I'm really confused.

[Diapolo]

Unfortunately, on my 6970s it is actually appearing to be slower   I may have to revert this change.

edit: On my 6770 it's clearly faster and clearly slower on the 6970s... now I'm really confused.

The OpenCL compiler and resulting performance seems to be far away of beeing consistent :-/.
Are you on SDK 2.5 yet?

Dia

[-ck]

Unfortunately, on my 6970s it is actually appearing to be slower   I may have to revert this change.

edit: On my 6770 it's clearly faster and clearly slower on the 6970s... now I'm really confused.

The OpenCL compiler and resulting performance seems to be far way of beeing consistent :-/.
Are you on SDK 2.5 yet?

Dia

Was on 2.4, tried 2.5 and it's still consistently slower.

[-ck]

Just tried cgminer's latest head (@5411a13ad7140ced511782914e58395c10c76c1b)
and it's consistently slower than yesterday's head by about 10MH/s per GPU core.

And that's almost certainly the return code which affected mine also. I'll be reverting it shortly.

edit: reverting just that change fixes it instantly.

[kano]

Don't forget if your main pool is down at any particular time, you can always be running 2 pools (one as a backup) by using:
  ./cgminer -c pool1.cfg -c pool2.cfg

Where pool1.cfg contains your default pool to use and pool2.cfg contains what to use when pool1 is down

You can run it in this mode all the time and it will stay on pool1 until an outage occurs

[Meatball]

Don't forget if your main pool is down at any particular time, you can always be running 2 pools (one as a backup) by using:
  ./cgminer -c pool1.cfg -c pool2.cfg

Where pool1.cfg contains your default pool to use and pool2.cfg contains what to use when pool1 is down

You can run it in this mode all the time and it will stay on pool1 until an outage occurs

Is there a way to do this with the Windows binary version?

[RvdE]

Don't forget if your main pool is down at any particular time, you can always be running 2 pools (one as a backup) by using:
  ./cgminer -c pool1.cfg -c pool2.cfg

Where pool1.cfg contains your default pool to use and pool2.cfg contains what to use when pool1 is down

You can run it in this mode all the time and it will stay on pool1 until an outage occurs

Is there a way to do this with the Windows binary version?

Ofcourse. Just use cgminer.exe -c pool1.cfg -c pool2.cfg

or use multiple -o, -u, -p statements. Works fine here. (.ie cgminer.exe -o http://url_pool1:port -u username_pool1 -p pass_pool1 -o http://url_pool2:port -u username_pool2 -p pass_pool2)

[Meatball]

Ofcourse. Just use cgminer.exe -c pool1.cfg -c pool2.cfg

or use multiple -o, -u, -p statements. Works fine here. (.ie cgminer.exe -o http://url_pool1:port -u username_pool1 -p pass_pool1 -o http://url_pool2:port -u username_pool2 -p pass_pool2)

Nice, I'll give that a shot.  So, the second -o/u/p set is not used at all unless the first is down?  Will it automatically failback to the original?  Can you have a third or fourth set as well?

Just wondering