Topic: cgminer - CPU/GPU miner in C for linux/windows - page 5. (Read 81916 times)
Hey, have you added in the SSE2_x64_atom update yet?
Is it possible to make it compile without AMD APP SDK? To run it as a pure CPU miner on a machine without any GPU.
Updated tree:It should build now without opencl as a cpuminer only. The help message should say what it is compiled for after it's built.
Updated tree:
Fixed parameter parsing. Now short parameters should work, and it wont crash with invalid parameters.
Fixed parameter parsing. Now short parameters should work, and it wont crash with invalid parameters.
New windows binary:
http://ck.kolivas.org/apps/cgminer-ycros-2011-07-05.zip
http://ck.kolivas.org/apps/cgminer-ycros-2011-07-05.zip
Is it possible to make it compile without AMD APP SDK? To run it as a pure CPU miner on a machine without any GPU.
I'm working on that still.
Is it possible to make it compile without AMD APP SDK? To run it as a pure CPU miner on a machine without any GPU.
Updated tree:
I believe we've tracked down the cause of the libcurl bug as being signal handling in the dns lookup code. So I've disabled signal handling and this has allowed me to add multiple curl handles thus making each get work and submit work completely asynchronous rather than each getwork waiting on the previous one and so on. It is theoretically possible it could spend forever waiting for a dns resolve but I doubt this can happen in reality as the lookup code would have to timeout at some stage. I've also addressed a bug where it was possible after a longpoll that a gpu could be left idle without any work. New windows builds coming soon.
I believe we've tracked down the cause of the libcurl bug as being signal handling in the dns lookup code. So I've disabled signal handling and this has allowed me to add multiple curl handles thus making each get work and submit work completely asynchronous rather than each getwork waiting on the previous one and so on. It is theoretically possible it could spend forever waiting for a dns resolve but I doubt this can happen in reality as the lookup code would have to timeout at some stage. I've also addressed a bug where it was possible after a longpoll that a gpu could be left idle without any work. New windows builds coming soon.
I pulled from the new tree, and everything appears to be working now. Thanks.
Feature suggestion: Option to set a different worksize for each GPU.
Feature suggestion: Option to set a different worksize for each GPU.
Forgive my ignorance, but as this miner supports both GPU and CPU, does it "intelligently" pick which processor to use or do you have to tell it to either use the GPU or the CPU (or both)?
If it does not detect any gpus it will cpu mine. If it detects any gpus it will only gpu mine unless you explicitly tell it to cpu mine as well. I'm working on modifying the code to build in the absence of opencl code and be a pure cpu miner still if need be. 
Forgive my ignorance, but as this miner supports both GPU and CPU, does it "intelligently" pick which processor to use or do you have to tell it to either use the GPU or the CPU (or both)?
I've decided to rename this application cgminer which means "cpu and gpu miner" or "ck and garzik miner" or "c gpu miner" or... just plain cgminer.
So I've moved the git tree to
https://github.com/ckolivas/cgminer
and have started renaming files and have cleaned up the git log, rebasing it, for it to build with the name cgminer version 1.0.9
So I'm trying to clean all this code up for a meaningful release now.
So I've moved the git tree to
https://github.com/ckolivas/cgminer
and have started renaming files and have cleaned up the git log, rebasing it, for it to build with the name cgminer version 1.0.9
So I'm trying to clean all this code up for a meaningful release now.
Yes, thanks, that was it.
Gnu source is in config.h now
So it should be pulled in by everything
Make sure you have done ./autogen.sh and then ./configure
So it should be pulled in by everything
Make sure you have done ./autogen.sh and then ./configure
Yes, sure, it's still there. But the problem isn't with the header file. This commit breaks the build:
Quote
commit 5c2eee548c8d6f2e0d90f6f1631cf7d5b49fc3d8
Author: Con Kolivas <[email protected]>
Date: Sat Jul 2 13:46:17 2011 +1000
Fix redefinition of gnu source.
diff --git a/cpu-miner.c b/cpu-miner.c
index 6168713..72e0a6d 100644
--- a/cpu-miner.c
+++ b/cpu-miner.c
@@ -10,7 +10,6 @@
*/
#include "config.h"
-#define _GNU_SOURCE
#include
#include
And indeed, man CPU_ZERO says:Author: Con Kolivas <[email protected]>
Date: Sat Jul 2 13:46:17 2011 +1000
Fix redefinition of gnu source.
diff --git a/cpu-miner.c b/cpu-miner.c
index 6168713..72e0a6d 100644
--- a/cpu-miner.c
+++ b/cpu-miner.c
@@ -10,7 +10,6 @@
*/
#include "config.h"
-#define _GNU_SOURCE
#include
#include
Quote
...
SYNOPSIS
#define _GNU_SOURCE
#include
...
I'm not sure how it works on your system though. SYNOPSIS
#define _GNU_SOURCE
#include
...
Compilation fails on Fedora 14 32bit, can't find CPU_* macros for some reason:
Quote
gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -I./compat/jansson -O2 -Wall -msse2 -I/opt/ati-stream-sdk-v2.1-lnx32/include -g -MT minerd-cpu-miner.o -MD -MP -MF .deps/minerd-cpu-miner.Tpo -c -o minerd-cpu-miner.o `test -f 'cpu-miner.c' || echo './'`cpu-miner.c
In file included from cpu-miner.c:30:0:
miner.h:29:0: warning: "alloca" redefined
/usr/include/alloca.h:36:0: note: this is the location of the previous definition
cpu-miner.c: In function 'drop_policy':
cpu-miner.c:44:21: warning: unused variable 'param'
cpu-miner.c: In function 'affine_to_cpu':
cpu-miner.c:58:2: warning: implicit declaration of function 'CPU_ZERO'
cpu-miner.c:59:2: warning: implicit declaration of function 'CPU_SET'
cpu-miner.c:60:2: warning: implicit declaration of function 'sched_setaffinity'
In file included from cpu-miner.c:30:0:
miner.h:29:0: warning: "alloca" redefined
/usr/include/alloca.h:36:0: note: this is the location of the previous definition
cpu-miner.c: In function 'drop_policy':
cpu-miner.c:44:21: warning: unused variable 'param'
cpu-miner.c: In function 'affine_to_cpu':
cpu-miner.c:58:2: warning: implicit declaration of function 'CPU_ZERO'
cpu-miner.c:59:2: warning: implicit declaration of function 'CPU_SET'
cpu-miner.c:60:2: warning: implicit declaration of function 'sched_setaffinity'
That should be in /usr/include/sched.h which is in a virtually standard package for compiling anything: libc6-dev
Compilation fails on Fedora 14 32bit, can't find CPU_* macros for some reason:
Quote
gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -I./compat/jansson -O2 -Wall -msse2 -I/opt/ati-stream-sdk-v2.1-lnx32/include -g -MT minerd-cpu-miner.o -MD -MP -MF .deps/minerd-cpu-miner.Tpo -c -o minerd-cpu-miner.o `test -f 'cpu-miner.c' || echo './'`cpu-miner.c
In file included from cpu-miner.c:30:0:
miner.h:29:0: warning: "alloca" redefined
/usr/include/alloca.h:36:0: note: this is the location of the previous definition
cpu-miner.c: In function 'drop_policy':
cpu-miner.c:44:21: warning: unused variable 'param'
cpu-miner.c: In function 'affine_to_cpu':
cpu-miner.c:58:2: warning: implicit declaration of function 'CPU_ZERO'
cpu-miner.c:59:2: warning: implicit declaration of function 'CPU_SET'
cpu-miner.c:60:2: warning: implicit declaration of function 'sched_setaffinity'
In file included from cpu-miner.c:30:0:
miner.h:29:0: warning: "alloca" redefined
/usr/include/alloca.h:36:0: note: this is the location of the previous definition
cpu-miner.c: In function 'drop_policy':
cpu-miner.c:44:21: warning: unused variable 'param'
cpu-miner.c: In function 'affine_to_cpu':
cpu-miner.c:58:2: warning: implicit declaration of function 'CPU_ZERO'
cpu-miner.c:59:2: warning: implicit declaration of function 'CPU_SET'
cpu-miner.c:60:2: warning: implicit declaration of function 'sched_setaffinity'
Updated tree:
I put a careful counter on the number of queued items to ensure we don't fall between the cracks during an updated block and clearing of work that we end up without any work and one ore more threads idle. Also, since minerd now pre-queues work before the previous work is finished, there is no need to have extra queued work by default, so I've changed the default queue value to 0 and made it mean extra queued work instead.
I put a careful counter on the number of queued items to ensure we don't fall between the cracks during an updated block and clearing of work that we end up without any work and one ore more threads idle. Also, since minerd now pre-queues work before the previous work is finished, there is no need to have extra queued work by default, so I've changed the default queue value to 0 and made it mean extra queued work instead.
Thanks. I'm pretty sure I know what that is. The different cards need different kernels and they're both loading the same binary. I'll get to fixing that.
Updated tree: The binary kernel stored now includes the GPU name in the filename. This will allow separate binary kernels to be saved for each unique GPU type on the same machine which should fix this problem.
Can you change the name to something other than the now-misleading "cpuminer"?
I'll get around to it sooner or later. Trying to consolidate everything now to make sure it's all actually working :s
What does the output look like with -D until it has started getting HW errors?
Output from minerd
I didn't set --queue, --gpu-threads or --intensity, so these were at default values.
These lines look interesting:
Code:
[2011-07-04 01:42:48] GPU 1 found something?
[2011-07-04 01:42:48] No best_g found! Error in OpenCL code?
[2011-07-04 01:42:48] No best_g found! Error in OpenCL code?
This only happens with the last few versions of of minerd, an older version (before your "What next..." post) worked fine with both GPUs. Unfortunately I don't know at which exact version it stopped working.
Thanks. I'm pretty sure I know what that is. The different cards need different kernels and they're both loading the same binary. I'll get to fixing that.
Jump to: