I definitely agree. Push-based work distribution is the way to go. I just wanted to make as few changes as possible using existing RPC server. My hope was that BTC developers will evaluate the idea and make something better to get in the mainline. Perhaps we should just implement this 8334 push patch and propose it for inclusion?

Also, it's OK to have CPU generation in mainline. Just let the user decide how much resources he is willing to give. Something like how many lottery tickets he is willing to buy.

Its not for the masses obviously.  

Edit btc_miner.cl

Insert at the top

#pragma OPENCL EXTENSION cl_amd_media_ops : enable

change

#define rot(x, y) rotate(x, (uint)y)

to

#define rot(x, y) amd_bitalign(x, x, (uint)(32-y))

See Stream SDK OpenCL Programming Guide for details.

I'll try to add some macro to resolve this by default.

If some commodity (bitcoin for example) has changed it's price significantly against some well established currency ($) shouldn't its trading volume decline? Because volume of 50 000 BTC at 0.06$ and 0.2$ represents proportionally different volume in $. It will stay the same only if the actual volume of the economy is larger.

Perhaps BTC exchangers should provide volume data in their other currencies? This will provide more realistic view in my opinion.

Just fixed problem with getwork (different miners were showing same results). Updated to SVN 173. See for windows build in first post.

Sorry guys, I screwed it with the update to SVN 170. There is a bug in getwork patch that makes poclbm useless with more than a single instance. Until this is fixed anyone using more than one instance should use previous version of the patch (against SVN 166). Win32 binary bitcoin-getwork-svn166-win32.7z

Well, this is not good. I will take a look to figure it out.

The block won't show up. This happens when the network discovered block just after last request for work by the miner. This is the drawback of the pull manner in which getwork... works. The probability for this to happen is 1/60 with ask rate of 10 seconds and 1/120 with ask rate of 5 seconds. It will be better if work is provided in 'push' manner, but I didn't want to complicate the client with separate server thread.

From now on I'll post latest versions only in the initial post of this thread.

The miner should display 'bitcoin is downloading blocks...' until all blocks are downloaded. Please test. This was added in the SVN 163 patched client.

David, I removed usage of vectors. So the '-w 128' is not relevant anymore. Of course you can grab the vectors version from git and use it like before. It is really difficult to optimize for all possible devices. Current version is kind of best for all.

bitcoin-getwork-svn170-win32.7z

poclbm_win32_exe.7z Wrong kernel was packed in the py2exe version, now fixed. Removed AMD OpenCL.dll to prevent conflicts.

I also reverted back to scalars. With vectors it was faster, but required hardware specific tweaks and was making it slower for others. Unfortunately OpenCL is not mature enough to provide means of automatic performance optimization.

Thanks Jef! There is new version that should work on Nvidia now. I also changed default getwork request rate to 5 seconds to reduce the risk of solving stale block. The patch itself has now one more check to not show 'proof of work found' in this case.

Can someone with Nvidia please test this, it should resolve the 'code selection failed to select' issue.

Jef, at least it's now clear the problem is in the bytereverse(x) macro. Please try to replace it with:

uint bytereverse(const uint x)
{
   uint result;
   uchar* b = (uchar *)&x;
   uchar* l = (uchar *)&result;
   l[0] = b[3];
   l[1] = b[2];
   l[2] = b[1];
   l[3] = b[0];
   return result;
}

jef.blanc, try to replace the rotate() function with some native rotate left. rotate() is compiled to bit_align AMD specific instruction on AMD. Also there are problems with casts... I switched to uint2 vectors and all operations with mixed types (vector, scalar) work fine on AMD, but Nvidia compilator has problems.

The IDs stay the same as long as there are no changes in hardware (new cards for example).

The -w parameter sets the number of 'work group size' (local threads). Unfortunately it's very difficult to determine the optimal value for this because it's different on different hardware platforms. The default is to use maximum reported by OpenCL for the specific hardware. This also was the behavior of previous versions. Last days I tried an optimization which tests two hashes in kernel run and it is 1-2% slower with default local threads (5770 - 256), but 5-6% faster with half of them (128) and global threads little bit more (-f 35). Generally, with default parameters one should achieve about the same or slightly worse performance than before.

bethel, what are 5870s showing at stock frequency (850 MHz)? Perhaps one of the cards throttles down?

Latest version has new parameter, -w, to set work group size. I have best results on 5770 with -w 128 -f 35.

Jimbo, please try this and see if the tool shows OpenCL is supported. It would be helpful if you post a screenshot.

Try to update your GPU driver. See http://forums.nvidia.com/index.php?showtopic=150585

It seems OpenCL is still problematic on Nvidia GPUs. Unfortunately I don't have one to try to make a PyCuda miner.

It only tries to keep single kernel run under specific time by changing the number of 'global' threads. If you start a game, kernel execution will get slower. The number of threads will then be gradually adjusted to achieve the desired execution time.

By default this time is 1/60 of a second. If shorter i.e. 1/120 sec it will leave more time for other GPU tasks.

This is adjusted with the '-f' switch.

Right after these lines is there something like:

ProcessBlock: ACCEPTED
sending: inv (37 bytes)

If so (and you are sure this is the block in question) it was announced to the network, but another block got included in the chain instead. Do you have other blocks after that?

BTW, if you want poclbm to crunch slower, start it with something like -f 400. Experiment with the number.

The miner asks for work at an interval of 10 seconds. If there is a new block from the network in the last such interval your client won't even try to announce your own next block. I am not sure, but I think this is the behavior of the original client too. Please take a look at your debug.log and if possible send me an excerpt from around where this happened. Look for terms like "SetBestChain" and "height=" if you know the block number.

Sometimes the client just doesn't show the new transaction right away.