OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 809.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ?? on ??

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) Sad

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. Undecided

oppiet30

newbie

Activity: 5

Merit: 0

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.

tigereye

member

Activity: 79

Merit: 10

Quote from: ?? on ??

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

Quote

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...

miscreanity

legendary

Activity: 1316

Merit: 1005

Quote from: ?? on ??

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.

miscreanity

legendary

Activity: 1316

Merit: 1005

Quote from: ?? on ??

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.

gigica viteazu`

sr. member

Activity: 458

Merit: 250

beast at work

still no 1.5.3 version for windows ? Sad

Diapolo

hero member

Activity: 772

Merit: 500

Quote from: ?? on ??

Quote from: Diapolo on August 11, 2011, 08:15:38 AM

I would suggest that we should try to create a kernel which is based on the same kernel-parameters for phatk and phatk-Diapolo so that the users are free to chose which kernel is used. One thing is CGMINER kernel uses the switch VECTORS2, where Phoenix used only VECTORS (which I changed to VECTORS2 in my last kernel releases). It doesn't even matter to use the same variable names in the kernel (in fact they are different sometimes) as long as the main miner software passes the awaited values in a defined sequence to the kernel.

It must be way too early in the day, but this last sentence just confused
me utterly for the second time (read it first in your original post) Cheesy

I'll try again ^^! There is no need for the kernels to be equal inside (variable names and so on), but the parameters both kernels use (like base, PreVal0 and so on) and which are passed from the main miner software need to be the same in order to be compatible (use phatk, phatk-diapolo or whatever). Better now Cheesy

?

Dia

Diapolo

hero member

Activity: 772

Merit: 500

Quote from: ?? on ??

Quote from: -ck on August 11, 2011, 08:00:37 AM

ALUs are not the only way to judge performance.

Agreed: actual wall time MH/s is.

However, in this specific instance the two seem to be strongly correlated (which
isn't much of a surprise: execution units on GPU aren't anywhere as smart as
those on CPU).

Point in case: Diapolo's diagnostic turns out to be correct, I ran a parallel experiment
this morning between phoenix+phatk 2.2 and the latest git tree cgminer
(9df379ecc793b6266853 with phatk110810.cl).

Bottom line: cgminer is slower by ~3Mh/s per GPU core.

Also ... I started to look at how to integrate the phatk 2.2 into cgminer, but it's a
real headache: the original phatk code has been re-indented and changed all over
the place.

What would really be helpful is to somehow be able to drop in the latest phatk kernel
into cgminer without having to change it much. Barring that, having some sort of
script that can convert a pristine phatk kernel into a cgminer-compatible version
would be neat.

I will quote myself from the Phatk-thread Cheesy

!

Quote

The last kernel releases show, that it is a bit of trial and error to find THE perfect kernel for a specific setup. Phaetus and I try to use the KernelAnalyzer and our Setups as a first measurement, if a new Kernel got "faster". But there are many different factors that come into play like OS, driver, SDK, miner-software and so on.

I would suggest that we should try to create a kernel which is based on the same kernel-parameters for phatk and phatk-Diapolo so that the users are free to chose which kernel is used. One thing is CGMINER kernel uses the switch VECTORS2, where Phoenix used only VECTORS (which I changed to VECTORS2 in my last kernel releases). It doesn't even matter to use the same variable names in the kernel (in fact they are different sometimes) as long as the main miner software passes the awaited values in a defined sequence to the kernel.

Dia

Diapolo

hero member

Activity: 772

Merit: 500

Quote from: -ck on August 11, 2011, 08:00:37 AM

ALUs are not the only way to judge performance.

Correct, that's what I wrote in the Phatk thread, too. We also have to look at other factors, I only wanted to point out, that current git seems like a new hybrid version, whose performance is not clear Wink

.

Dia

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

ALUs are not the only way to judge performance.

Diapolo

hero member

Activity: 772

Merit: 500

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 Wink

.

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

d3m0n1q_733rz

sr. member

Activity: 378

Merit: 250

Random question about the SHA-256 hash so I know if I can maybe make a small change to speed up hashing in cgminer:
I've noticed the 8 trailing 0's at the end of the hashes. Why do these 0's occur and are they computed/always going to be 0's no matter what? If there will always be those 8 trailing 0's regardless of what block number we're at, it could be possible to simply keep them a constant in the code if we haven't already and speed up hashing by a slight margin.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

I have incorporated his changes into the main git tree now.

ah42

newbie

Activity: 14

Merit: 0

Quote from: -ck on August 10, 2011, 10:19:11 AM

Don't be scared. You're doing good work. I'll play with your changes and see if they break anything

Welcome back!
It's not so much about being scared; More that I didn't do a bunch of little commits and comment the specific changes. I would have liked to have done that...at least so they could be submitted as separate changesets/patches for you to look at.

I *have* done that for the next couple commits

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ah42 on August 05, 2011, 11:26:27 PM

Since Con is away...

I thought I'd take a try at integrating some of the recent changes in both phatk kernel threads. (here and here)
I've also changed the method used to specify various #defines for the kernels by simply specifying the defines as build options for clBuildProgram() instead of editing the .cl text on the fly. (so much simpler!)

Compared to the current kernel in cgminer 1.5.3, this does benefit from reduced ALU OPs, although not as much as either of the other phatk kernels:

1.5.3:
VLIW4: 1699 ALU OPs
VLIW5: 1376 ALU OPs

Mine:
VLIW4: 1694 ALU OPs
VLIW5: 1368 ALU OPs

My changes are here at github, but it's all in one big ugly commit, and not broken out by the individual changes, so i don't feel comfortable in the slightest offering a pull request to CK for it.

Don't be scared. You're doing good work. I'll play with your changes and see if they break anything

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: ?? on ??

...

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.

...

Yes that's in the README file but some people (I did the very first time also) accidentally skip it.

Endeavour79

full member

Activity: 174

Merit: 100

Quote from: boss cat on August 09, 2011, 03:39:02 PM

Quote from: dlasher on August 09, 2011, 12:16:51 PM

Quote from: boss cat on August 08, 2011, 04:16:08 PM

Quote from: Endeavour79 on August 08, 2011, 04:00:46 AM

Quote from: burtyb on August 01, 2011, 07:30:46 AM

I tried cgminer on a couple of my boxes last night and woke up to find 3/4 GPU marked as DEAD on one and 2/4 DEAD on another. Trying to restart the DEAD GPU doesnt seem to do anything on either machine (restarting the ones still running did seem to restart them OK). Both boxes have been running for weeks using poclbm without errors. Running the 1.5.3 binary on Ubuntu (3xHD5870 and HD6310).

Anyone else seeing problems with DEAD GPU that won't recover unless cgminer is restarted?

BB.

Restart dead GPUs does not work for me too. Win7 64bit, Catalyst 11.7

Me too. LinuxCoin beta final

In my testing, under Fedora14, SDK2.4, restart GPU works in 100% of my 5xxx series cards, and 0% of my 6xxx series cards.

Not for me. It won't restart either gpu on my 5970.

Does not work in Win 7 x64 on HD69xx and HD58xx for me.

tigereye

member

Activity: 79

Merit: 10

I apologize for repeating the question but it's been about 6 pages and it appears to have been overlooked.

I'm getting the following error when trying to run the latest version of cgminer (compiled from git checkout) on linuxcoin.

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.

But I managed to get it to compile successfully with the following:

Code:

./autogen.sh
./configure
./make

Unfortunately, after it compiled I get the above error.
After configuring, it reports that OpenCL is enabled. When I do "./cgminer --ndevs" it properly reports my number of GPUs.

Has anyone else run into this problem on their machines?
It works perfectly on another linuxcoin install, but not on this one rig...but I don't know what separates this rig from the others. I must have missed installing some package? or other prerequisite?

Thanks for any help you can provide!

miscreanity

legendary

Activity: 1316

Merit: 1005

The problem I've noticed is that there are occasional lock-ups even with the temperature steady. My 69xx cards won't start again even if cgminer is restarted. They don't respond to anything and require a cold boot.

d3m0n1q_733rz

sr. member

Activity: 378

Merit: 250

I was just thinking, how about instead of restarting on lockups, we work to throttle the work load once the temp. reaches a preset value? Most of these cores have an internal temperature sensor. We just have to monitor it and throttle back to let it cool so as to let it continue mining. However, it would be a good idea to let the user know when the temperature is being reached so as to allow for user intervention to fix the cooling issue that it is having.

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