If we can get you FPGAs, would you be willing to support those in cgminer?
But of course. It would be a self-fulfilling donation then which is better than just giving me the equivalent amount of BTC, as was the 7970 donation and much better cgminer support for GCN cards as a result. Continuing to support would be guaranteed if I owned one of the devices.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 593. (Read 5806103 times)
April 25, 2012, 10:43:42 AM
April 25, 2012, 10:09:50 AM
Well, you could withdraw support from cgminer... but I think the better course of action is to modularize all of the processor types and abstract them from the cgminer core.
Yes, that's what I did when I added FPGA support originally. The code is still in the same tree, however. 
April 25, 2012, 09:56:31 AM
Well, you could withdraw support from cgminer... but I think the better course of action is to modularize all of the processor types and abstract them from the cgminer core.
You can then concentrate on developing the cgminer core and the gpu module and others can concentrate on the FPGA, ASIC, etc... modules. Tear all of the built in code that's in there so far and put it in a separate module for each type of device. Then call those modules from cgminer to do their thing, have them return the proper data and let the cgminer core handle sending the results/requesting the getworks from the server and displaying the results to the screen.
You can then concentrate on developing the cgminer core and the gpu module and others can concentrate on the FPGA, ASIC, etc... modules. Tear all of the built in code that's in there so far and put it in a separate module for each type of device. Then call those modules from cgminer to do their thing, have them return the proper data and let the cgminer core handle sending the results/requesting the getworks from the server and displaying the results to the screen.
April 25, 2012, 09:55:43 AM
and don't forget the dd-wrt support with it :-)
So how does dd-wrt relate to openwrt (which I'm currently using on a tp-link router)?
April 25, 2012, 09:44:27 AM
and don't forget the dd-wrt support with it :-)
April 25, 2012, 09:06:24 AM
I agree with your views.
I don't have any FPGA and don't plan on ever having one.
Maybe start FPGAminer project
but let us concentrate on GPUs for now because a majority of miners are using them right now.
FPGA is just a minority ...
I don't have any FPGA and don't plan on ever having one.
Maybe start FPGAminer project
but let us concentrate on GPUs for now because a majority of miners are using them right now. FPGA is just a minority ...
Minority or not, I like cgminer so much I'm supporting ztex there myself. There has been some extra work for ckolivas as I adapt to cgminer's coding style but it is more or less easy to keep most changes separate fromt he main cgminer code. I do think ckolivas' time is best spent making cgminer even better and more stable rather than implementing fpgas there, seeing he is very good in the gpu support, as it is in his personal interest anyway
I think cgminer as a gpu + fpga miner is unbeatable, and I'll do all I can to keep it that way. We can always fork it, but I think as FPGAs become more mainstream it is good for the community as a whole if it stays in the same place.
April 25, 2012, 08:45:22 AM
By the way, I'm having great trouble justifying the FPGA support in cgminer. It's taking me a fair amount of time vetting all the code that comes in, dealing with the drama of different coders not getting on, and that I don't have an FPGA so the code does not benefit me, nor am I earning anything off supporting FPGAs. So once again I find myself in a quandary about whether I should even be supporting them at all or not (like CPU mining, but for precisely the opposite reason!). So unless this gets easier, and it looks like it will only get harder, there is a very real possibility that someone like Luke-jr will fork the FPGA code into a separate project (he has even suggested he will) and I'll stop supporting it. I'm just giving advance warning here to people about this issue. I know it's just me whining, and harsh, but the fact is that the effort has to come from somewhere, and I do not have infinite time on my hands.
I agree with your views.
I don't have any FPGA and don't plan on ever having one.
Maybe start FPGAminer project
but let us concentrate on GPUs for now because a majority of miners are using them right now. FPGA is just a minority ...
April 25, 2012, 08:23:52 AM
Silly me! I don't normally run autogen when recompiling. Guess I'll make that habit for cgminer.
Thanks!
Thanks!
April 25, 2012, 08:17:03 AM
If we can get you FPGAs, would you be willing to support those in cgminer?
But of course. It would be a self-fulfilling donation then which is better than just giving me the equivalent amount of BTC, as was the 7970 donation and much better cgminer support for GCN cards as a result. Continuing to support would be guaranteed if I owned one of the devices. April 25, 2012, 08:14:30 AM
I am confused... Anyone have any idea what's up?
You "forgot" to re-run autogen. For some reason, cgminer's Makefile doesn't do it. April 25, 2012, 08:11:16 AM
Ok, I'm confused. I just updated two separate machines:
git pull
make clean
ATISTREAMSDKROOT="/opt/AMD-APP-SDK-v2.4-lnx32/" CFLAGS="-O2 -Wall -march=native" ./configure --enable-bitforce --bindir="/opt/miners/cgminer" --prefix="/opt/miners/cgminer"
make
Both machines are basically the same... here's what I get as a resulting binary:
Machine 1:
./cgminer --version
cgminer 2.3.4
Machine 2:
./cgminer --version
cgminer 2.3.3
Machine 1 fetch head:
effdbaf2062e54ba220974a9ab364a4f94088d9e not-for-merge branch 'kernel' of https://github.com/ckolivas/cgminer
0e916802ce80465282638728cede0d62fd2d723e branch 'master' of https://github.com/ckolivas/cgminer
Machine 2 fetch head:
effdbaf2062e54ba220974a9ab364a4f94088d9e not-for-merge branch 'kernel' of https://github.com/ckolivas/cgminer
0e916802ce80465282638728cede0d62fd2d723e branch 'master' of https://github.com/ckolivas/cgminer
I am confused... Anyone have any idea what's up?
git pull
make clean
ATISTREAMSDKROOT="/opt/AMD-APP-SDK-v2.4-lnx32/" CFLAGS="-O2 -Wall -march=native" ./configure --enable-bitforce --bindir="/opt/miners/cgminer" --prefix="/opt/miners/cgminer"
make
Both machines are basically the same... here's what I get as a resulting binary:
Machine 1:
./cgminer --version
cgminer 2.3.4
Machine 2:
./cgminer --version
cgminer 2.3.3
Machine 1 fetch head:
effdbaf2062e54ba220974a9ab364a4f94088d9e not-for-merge branch 'kernel' of https://github.com/ckolivas/cgminer
0e916802ce80465282638728cede0d62fd2d723e branch 'master' of https://github.com/ckolivas/cgminer
Machine 2 fetch head:
effdbaf2062e54ba220974a9ab364a4f94088d9e not-for-merge branch 'kernel' of https://github.com/ckolivas/cgminer
0e916802ce80465282638728cede0d62fd2d723e branch 'master' of https://github.com/ckolivas/cgminer
I am confused... Anyone have any idea what's up?
April 25, 2012, 07:53:44 AM
If we can get you FPGAs, would you be willing to support those in cgminer?
But of course. It would be a self-fulfilling donation then which is better than just giving me the equivalent amount of BTC, as was the 7970 donation and much better cgminer support for GCN cards as a result. Continuing to support would be guaranteed if I owned one of the devices. 
April 25, 2012, 06:52:16 AM
umm have you guys seen any issues with memory usage with cgminer under win 7 x64?
It seems like a memory leak. It doesn't go above 400mb in peak working set(taskmgr) yet slowly all of my ram is filled and then the inevitable happens. Everything goes to hell. Quitting the program doesn't free the used ram. Only reboot helps.
I have 2x 5970 2x 5870 with 11.12 catalyst + 2.5 sdk.
It seems like a memory leak. It doesn't go above 400mb in peak working set(taskmgr) yet slowly all of my ram is filled and then the inevitable happens. Everything goes to hell. Quitting the program doesn't free the used ram. Only reboot helps.
I have 2x 5970 2x 5870 with 11.12 catalyst + 2.5 sdk.
April 25, 2012, 06:47:42 AM
By the way, I'm having great trouble justifying the FPGA support in cgminer. It's taking me a fair amount of time vetting all the code that comes in, dealing with the drama of different coders not getting on, and that I don't have an FPGA so the code does not benefit me, nor am I earning anything off supporting FPGAs. So once again I find myself in a quandary about whether I should even be supporting them at all or not (like CPU mining, but for precisely the opposite reason!). So unless this gets easier, and it looks like it will only get harder, there is a very real possibility that someone like Luke-jr will fork the FPGA code into a separate project (he has even suggested he will) and I'll stop supporting it. I'm just giving advance warning here to people about this issue. I know it's just me whining, and harsh, but the fact is that the effort has to come from somewhere, and I do not have infinite time on my hands.
If we can get you FPGAs, would you be willing to support those in cgminer?
April 25, 2012, 06:23:33 AM
The remaining two bounty payments have been sent:
To Ckolivas: http://blockchain.info/tx/a11d526aa66121ed4b0bb5cf828f2ab223e83a34471dbf6020e664dc219b52b5
Much appreciated, thanks To Ckolivas: http://blockchain.info/tx/a11d526aa66121ed4b0bb5cf828f2ab223e83a34471dbf6020e664dc219b52b5
April 25, 2012, 06:09:43 AM
I paid luke 5BTC for the share log solution:
http://blockchain.info/tx/7732db071b843e378b458b447c4962b0ffb22d638da77096238cd266fc847eef
ckolivas, if you don't like the share log idea and want to do something else officially, I'm willing to still pay you the original 15 BTC since I should have anticipated the fact that someone else might have created a solution in the short time between when I posted the request and when you saw the bounty and decided to do something else.
Just let me know what you prefer.
It's only money and you've already given some of it to luke who did the work. Why should I make you pay more than you originally offered? Luke's code is fine, but if you want me to include it, it'll have to be a proper pull request and fully documented as well since he'll get even more bounty according to your original offer if I include the code. http://blockchain.info/tx/7732db071b843e378b458b447c4962b0ffb22d638da77096238cd266fc847eef
ckolivas, if you don't like the share log idea and want to do something else officially, I'm willing to still pay you the original 15 BTC since I should have anticipated the fact that someone else might have created a solution in the short time between when I posted the request and when you saw the bounty and decided to do something else.
Just let me know what you prefer.
Gotta be quick to get the quick bucks it seems. I'll go back to the boring slow grind work instead
Awesome, thanks.
The remaining two bounty payments have been sent:
To Luke: http://blockchain.info/tx/ba031cdf4efdaf4a7f6bce52442539c6a415b5c612f194c04a4a4971cfdebb9b
To Ckolivas: http://blockchain.info/tx/a11d526aa66121ed4b0bb5cf828f2ab223e83a34471dbf6020e664dc219b52b5
April 25, 2012, 04:32:03 AM
By the way, I'm having great trouble justifying the FPGA support in cgminer. It's taking me a fair amount of time vetting all the code that comes in, dealing with the drama of different coders not getting on, and that I don't have an FPGA so the code does not benefit me, nor am I earning anything off supporting FPGAs. So once again I find myself in a quandary about whether I should even be supporting them at all or not (like CPU mining, but for precisely the opposite reason!). So unless this gets easier, and it looks like it will only get harder, there is a very real possibility that someone like Luke-jr will fork the FPGA code into a separate project (he has even suggested he will) and I'll stop supporting it. I'm just giving advance warning here to people about this issue. I know it's just me whining, and harsh, but the fact is that the effort has to come from somewhere, and I do not have infinite time on my hands.
April 25, 2012, 03:18:47 AM
if you write support of ztex is this only 1.15x or y too?
1.15y support will come soon, but since I don't have one such board it will initially be based on reverse engineering and voluntary external testing. This approach is bound to take some time but we'll get there.
If someone wants to handle donations towards a board to send me that would likely speed things up (and Stefan will most likely give some discount based on his OS program) but it is not really needed, just helps a bit.
April 25, 2012, 01:54:03 AM
- Initial Ztex support 1.15x board.
April 25, 2012, 01:50:38 AM
if you write support of ztex is this only 1.15x or y too?
Jump to: