On linux you should disable crossfire and use Catalyst 11.4/SDK2.4. It works.

Apparently, on 5870 for some reason the generated binary is not optimal. If someone with such card (or 5970) is willing to help me test and fix that, please PM me.

Damn...still that 5870 issue...hmmm wanna have one for tests

Fixed a couple of bugs:

* Progress indicator finally fixed
* Kernel reworked - there are separate codepaths, one for VLIW5 (interlaced uint2+uint to get best utilization) and another for VLIW4 architectures. Additional optimizations implemented.
* Added -D command-line option. This tends to increase speed at the cost of reduced desktop responsiveness (kinda like Phoenix AGGRESSION parameter)
* Additional marginal speedup can be achieved by using -G 3 option at the command line (or even -G4) - but that requires more memory and faster, multicore CPU
* the curl handles leak was fixed - no more "connection failed after half an hour of work" issues.

The code changes are confirmed to be incompatible with ATI Stream SDK 2.1 and 2.2. Please _DO NOT_ use older than 2.3 versions.


Not implemented yet:

* ADL thermal monitoring for ATI
* Failover extension (used in deepbit.net)


Download:

64-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz

32-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgz

^^ This means you don't have the SDK installed or you haven't done export LD_LIBRARY_PATH=/path/to/sdk/lib/<arch> prior to running it.

You should also make sure the OpenCL runtime detects your GPU - by running the CLInfo sample from the SDK.

Just wait, people, there are still lots of bugs I am working on A new release will be done in a couple of days, hopefully fixing them all. The reconnect issue is due to missing deinitialization of a curl handle and this will definitely be resolved. We still have problems with 6990 and this afternoon I had to rewrite the whole kernel (replacing uint4 with interlaced uint2+uint) to get that GPR thing working reliable on all VLIW5 cards.

Hello,

Yes, that's one of the bugs I have collected thanks to people that tested the alpha (related to an integer overflow). Another one found is related to missing deinitialization of certain curl handles that creates big problems after some time spent in mining. Another problem was related to improper BFI_INT replacement on 69xx cards (fixed now). Finally, the 69xx codepath is not optimal and I am now currently working on a separate vliw4 codepath that is best optimized for 69xx devices. Sorry for those, but your input was very helpful for me to identify and fix those issues. A new testing release will be ready soon with those problems resolved.

Another thing is that we're walking on the verge with those uint4 vectors...on my 6870 I'm getting 41 GPR usage currently. If that rises to 42 for some reason, performance degrades disastrously as the number of wavefronts/cu drops. I still need to find a way to reduce the GPR usage - cause on some other cards, the compiler is unable to generate code that keeps to 41GPRs thus generating slow-performing code. Since I am doing that by carefully reordering stuff, it's a bit wacky and not reliable at the moment...still need some work on that.

Hmm...perhaps an ISA dump would be useful to debug the problem.

You can do that by running export GPU_DUMP_DEVICE_KERNEL=3 prior to running hashkill (you need to be in a writable directory like e.g /tmp).

Then after say 30 seconds, stop execution (ctrl-c) and look for a file named bitcoin_<GPUmodel>.isa (e.g bitcoin_Cypress.isa). Please paste this file contents so that I have a look at it.

P.S. you would need ~ 5-10 seconds until speed peaks at maximum, it usually starts at lower speed and gradually increases. As for switches, you might try -G 3 and/or -D and see if it affects performance positively.

P.S 2: also please do not run the 32-bit version on a 64-bit system: it tends to be way slower. And (again) use SDK 2.3 or newer.

OK - fixed some stuff and rebuilt.

The progress indicator issue should be gone.
Removed dependency on OpenCL.so.1 so that it can be run with older SDKs
Built a 32-bit static-linked binary

64-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz

32-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgz

That's weird. Does the pool report submitted shares?

Ah, I see now - it uses signed int and you're mining faster than 2G per 3s. OK, fixing that now...

Well it would require code changes as well as changes in the autoconf/automake part to build properly on windows/cygwin cause right now it depends a lot on some linux specific stuff (like procfs and/or some linux-specific API functions). However, windows version is not in my near plans. It is more likely that an MacOSX port will be done first as I had such requests for the hash cracker and it would be relatively easy. Porting to windows would be much more difficult though.

Please try it with SDK 2.3 (or later, but since 2.4 updates the ICD files, I would recommend 2.3). It is relatively safe and compatible with 2.1 - you just download and unpack it and point LD_LIBRARY_PATH to SDK2.3's library path.

Anyway, peak performance would be achieved with 2.4 as the compiler aggressively optimizes some parts of the code, lowering the number of ALU instructions needed.

SDK 2.1 is too old...it has no OpenCL 1.1 support and is not thread-safe. It has also other problems, e.g rotate() not generating BIT_ALIGN_INT instructions and stuff.

P.S retested phoenix with WORKSIZE=128 and without FASTLOOP. It is indeed faster, in fact as fast as poclbm (263M/s). hashkill is still faster at 271M/s

The source of the plugin will be available once it reaches "production" quality, right now I would be a bit embarassed to put it in public, cause it's ugly I need some more test feedback though as I don't have the variety of hardware to test...

Hello,

The dependance on OpenCL.so.1 is my mistake, I have built it against SDK 2.4 and should fix that. A quick workaround would be to create a symlink libOpenCL.so -> libOpenCL.so.1. Also, it may not work with SDK < 2.3 cause I set some environment variables introduced in 2.3 to speed up host-device transfers a bit and properly support multi-GPU without 100% CPU load


Yeah, this comes from the fact that the tool is a hash cracker anyway the bitcoin functionality is a testing one and yet has not been integrated properly yet so in this case we're reusing the generic deinitialization routine used for the hash cracking code. As I said, it's still an alpha, there are many things that need to be done before it reaches release quality


As for 32-bit version, there are some issues with cross-compilation at that moment that I am working on currently. Should be ready in 1-2 days.

As for windows version - not planned, sorry.

Hello,

I am developing an opensource linux CPU/GPU hash cracker and recently got introduced to bitcoin world and decided to write a bitcoin miner as part of my program (as I can reuse most of my sha256 code).

My bitcoin plugin is in alpha stage, but it already does some pretty handy stuff, e.g:

* Does BFI_INT patching
* Is extremely optimized using some optimization tricks I borrowed from my sha256 plugin (40 GPRs, less than 2890 ALU ops and over 97% ALUPacking on 6870 - it's VLIW5)
* Supports multi-gpu configurations (no need to run separate instances for each device)
* Supports NVidia and ATI (4xxx support is broken though for some reason I have yet not identified)
* Supports long polling
* Does not quit on connection failure, instead it retries after 20 seconds
* Has a relatively smart getwork asking mechanism that does not generate much network traffic and is suitable for pools like bitcoinpool.com where efficiency is important
* Integrated support for getting stats from pools (currently only bitcoinpool.com, deepbit.net and mining.bitcoin.cz)
* Is simple to use
* Preserves high performance without sacrificing desktop responsiveness

It is in alpha stage and at that point I prefer not to release the source of the plugin (except the kernels that look ugly ). Nevertheless, I have compiled a x86_64 binary, statically linked (so that you don't have to deal with dependency issues):

64bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz

32-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgz

Installation is simple - just run sudo ./install.sh (it requires superuser privileges in order to copy the plugins and kernels to /usr/share/)

Usage is also simple, just run:

hashkill-gpu -p bitcoin user:password:host:port [-a addopts]

e.g

hashkill-gpu -p bitcoin gat3way:mypassword:bitcoinpool.com:8334 -a gat3way

tested with bitcoinpool.com, deepbit.net and mining.bitcoinpool.cz

the -a option provides a way to get stats from the pool, you need to provide your API key or your username (bitcoinpool.com). If you do that, you get stats on curreent reward by pressing the enter key while mining.


You can try it if interested. BTW it is very fast, probably among the fastest miners out there. I did some tests with the latest versions of poclbm, phoenix and hashkill on my 6870 card (stock clocks) and the results are:


There is a screenshot: