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

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

Silly me!  I don't normally run autogen when recompiling.  Guess I'll make that habit for cgminer. 

Thanks!

The question that really needs to be asked is: will this change your current policy of all Icarus driver changes going through Kano (which allows him to continue breaking it, and neglects all the fixes and optimizations I've made), and instead consider merges based on their actual code quality?

You "forgot" to re-run autogen. For some reason, cgminer's Makefile doesn't do it.

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?

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.

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.

If we can get you FPGAs, would you be willing to support those in cgminer?

Much appreciated, thanks 

Awesome, thanks.

The remaining two bounty payments have been sent:

To Luke: http://blockchain.info/tx/ba031cdf4efdaf4a7f6bce52442539c6a415b5c612f194c04a4a4971cfdebb9b
To Ckolivas: http://blockchain.info/tx/a11d526aa66121ed4b0bb5cf828f2ab223e83a34471dbf6020e664dc219b52b5

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.

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.

if you write support of ztex is this only 1.15x or y too?

NEW VERSION - VERSION 2.3.4, 25 APRIL 2012

The release archive for this is much bigger because of included firmware for ztex boards. The version number is only a minor increment because it is mostly bugfixes for any features already working, and extra features should not affect existing working code.

Human readable summary:
Status window fixes for >8 devices.
Ztex support
Information at startup if config file is loaded
(advanced) gpu-map option for when OpenCL and ADL disagree on device numbering
API thread will restart properly if cgminer is restarted from the menu, and this hopefully will fix the ADL deciding to stop reporting fanspeeds by successfully restarting cgminer.
More information is given off with -n on the command line now.
You can increase the queue much more than 10 now if so desired.
Updated miner.php
Better Icarus support
First ZTEX FPGA support.

Full changelog:
- Extensively document the cause of GPU device issues and the use of --gpu-map.
- Support for share logging
- Detect poorly performing combination of SDK and phatk kernel and add verbose
warning at startup.
- Icarus update to new add_cgpu()
- Icarus driver working with Linux and Windows
- api.c fix unused variable compile warning
- Display all OpenCL devices when -n is called as well to allow debugging of
differential mapping of OpenCL to ADL.
- Add a --gpu-map option which will allow arbitrarily mapping ADL devices to
OpenCL devices for instances where association by enumeration alone fails.
- Increase upper limit on number of extra items to queue as some FPGA code can't
yet reliably keep many devices busy.
- Display configuration file information when -c option is passed and only when
file exists on loading default config file.
- Display configuration file loaded, if any, and debug output if configuration
file parsing failed.
- Add missing ztex header to Makefile for distribution.
- Document long-form COM port device names on Windows, required to specify
serial ports above 9
- Include ztex bitstreams firmware in distribution and install if configured in.
- Style police on driver-ztex.c
- work_restart should only be changed by cgminer.c now
- Shut down the api cleanly when the api thread is cancelled. This should allow
the api socket to be closed successfully to next be reopened with app_restart.
- Make a union for cgpu device handles, and rename "device" to "device_ztex"
since it's Ztex-specific
- Initialise name variable.
- Remove unnecessary check for variable that always has memory allocated.
- Bugfix: Missing "break" no-op in default case
- Make the status window and log window as large as can fit on startup,
rechecking to see if it can be enlarged after the fact. This allows any number
of devices to be displayed provided the window is made long enough without
corrupting the output.
- Style police on libztex.c.
- API add removepool like the screen interface
- api.c escape required characters in return strings + pools returns the
username
- Set lp_path to NULL after free for consistency.
- Removing dmalloc import left behind by mistake
- Fixing leak in resp_hdr_cb
- miner.php warning highlight GPU stats if they are zero (e.g. ADL not enabled)
- miner.php highlight any device that isn't 'Enabled'
- miner.php highlight any Status that isn't 'Alive'
- miner.php optionally support multiple rigs
- Initial Ztex support 1.15x board.

do you have an update?

I commented on a couple of minor issues with his code, he modified it, and I've included it in my git tree now.

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.

Gotta be quick to get the quick bucks it seems. I'll go back to the boring slow grind work instead

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.

I just used 0.999985 because that is the actual difficulty for a "diff 1" share for most pools since a diff 1 share is actually 0x00000000FFFF0000000000000000000000000000000000000000000000000000 but in practice most pool software actually uses 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF instead for simplicity of validation (they can just make sure that the hash starts with 8 zeros and don't have to do any actual large integer comparisons) and that target translates to slightly less than a difficulty of 1.0000.

So in other words, this is what I mean by difficulty:  https://en.bitcoin.it/wiki/Difficulty

Converting the target to difficulty is one of the things I didn't want to have to figure out myself in C/C++  I have code to do convert between difficulty and target and the 'bits' representation of target that is actually used in a block, just not in C/C++.  So I don't care which format is used since I can convert it as part of my analysis.  I just suggested difficulty because it was terse.  Target is equally fine with me, but it would then probably have to be in something like a seperate share log as luke was doing since there is no reasonable way to output the massive hex target in the normal output.

P.S.  Luke sharelog is mostly working now, so if you like it, you're welcome to avoid more work.   If you don't want to accept luke's solution, I'll probably still pay him an extra 5BTC for his effort since it works and is useful.