Phoenix - Efficient, fast, modular miner

[Diapolo]

If NVIDIA has OpenCL 1.1 drivers, they should support uint3 ... but as I observed, too, Phoenix crashes in

Code:

self.kernel.search(...)

. Perhaps a certain parameter is not valid there. I had

Code:

self.size = (nonceRange.size / rateDivisor) / self.iterations

in my mind, because for VECTORS3 rateDivisor is 3 and so self.size is not correct, because nonceRange.size is perhaps not dividable by 3?

Dia

[TeaRex]

You can also use -q 0 to disable the queue entirely.

Hmmm... at -q 0 Phoenix (current git running on Windows 7 x64, 64-bit Python 2.7.2) just keeps complaining that the queue is empty and never starts any actual mining.

The queue issue seems to be the reason why I get relatively high amounts of rejects when running against a local proxy; the proxy adds another layer of pre-fetching which of course makes the issue worse (and which you, jedi95, aren't responsible for at all).

[Diapolo]

You can also use -q 0 to disable the queue entirely.

Hmmm... at -q 0 Phoenix (current git running on Windows 7 x64, 64-bit Python 2.7.2) just keeps complaining that the queue is empty and never starts any actual mining.

The queue issue seems to be the reason why I get relatively high amounts of rejects when running against a local proxy; the proxy adds another layer of pre-fetching which of course makes the issue worse (and which you, jedi95, aren't responsible for at all).

I can confirm this, -q 0 is a no got currently.

Dia

[ummas]

@jedi95
 Sorry for my error, i have mssspeled. Of course i ment VECTORS.

[jedi95]

You can also use -q 0 to disable the queue entirely.

Hmmm... at -q 0 Phoenix (current git running on Windows 7 x64, 64-bit Python 2.7.2) just keeps complaining that the queue is empty and never starts any actual mining.

The queue issue seems to be the reason why I get relatively high amounts of rejects when running against a local proxy; the proxy adds another layer of pre-fetching which of course makes the issue worse (and which you, jedi95, aren't responsible for at all).

I can confirm this, -q 0 is a no got currently.

Dia

Sorry about that, I forgot that -q 0 only works in my current development version. It's an ugly workaround so I can test some things for rollntime.

The other solution is to use an askrate, which will reduce the problem.

Askrate can be specified by using this format for HTTP connections:
http://login:password@poolname.com:8332/;askrate=20

[Elder III]

Using Phoenix 1.72 with 12.1 Preview drivers and 2.6 SDK - poclbm Aggression 7 - Worksize 64 - I'm getting ~433 mhash on my HD 6970 at Stock settings and voltage.... I'm delighted with those results, esp. considering that it's not using 100% of a CPu core now either.  

[Diapolo]

Using Phoenix 1.72 with 12.1 Preview drivers and 2.6 SDK - poclbm Aggression 7 - Worksize 64 - I'm getting ~433 mhash on my HD 6970 at Stock settings and voltage.... I'm delighted with those results, esp. considering that it's not using 100% of a CPu core now either.  

poclbm kernel is at least 10 MH/s slower than my phatk version on my system with 6950, strange.

@jedi: Any reason to not use the latest pyOpenCL version for Phoenix? Perhaps there lies the vec3 problem? I read a bit in it's documentation and it seems a few commands Phoenix uses are now deprecated.

Dia

[Elder III]

Using Phoenix 1.72 with 12.1 Preview drivers and 2.6 SDK - poclbm Aggression 7 - Worksize 64 - I'm getting ~433 mhash on my HD 6970 at Stock settings and voltage.... I'm delighted with those results, esp. considering that it's not using 100% of a CPu core now either.  

poclbm kernel is at least 10 MH/s slower than my phatk version on my system with 6950, strange.

I was surprised to, as it seems that most people are using phatk or phatk2.  I haven't mined with that particular card (it's my gaming machine) in about 3 months, but I never got anything over 390-395 before, using GUIMiner.  I decided to mine again with it and was only getting ~366 mhash, so I tried out phoenix 1.72 and after a little tinkering and testing had my jaw drop when I saw it cranking out 433 or so mhash... going strong for over 24 hrs now too.

[jedi95]

Using Phoenix 1.72 with 12.1 Preview drivers and 2.6 SDK - poclbm Aggression 7 - Worksize 64 - I'm getting ~433 mhash on my HD 6970 at Stock settings and voltage.... I'm delighted with those results, esp. considering that it's not using 100% of a CPu core now either.  

poclbm kernel is at least 10 MH/s slower than my phatk version on my system with 6950, strange.

@jedi: Any reason to not use the latest pyOpenCL version for Phoenix? Perhaps there lies the vec3 problem? I read a bit in it's documentation and it seems a few commands Phoenix uses are now deprecated.

Dia

I know for a fact that uint3 vectors works under this version of pyOpenCL. I have been able to get the stock phatk to run with uint3 vectors enabled. The problems only occurs when I try to adjust the rateDivisor in the Python portion of the kernel. Dividing 2^N by 3 always has a remainder, so you end up sending bad work to the kernel.

This should at least give you a starting point:
https://github.com/downloads/jedi95/Phoenix-Miner/kernel.cl

The only change I made to the Python portion of the kernel is setting it to pass -DVECTORS3 to the compiler. Also note that without changing the rateDivisor your reported hashrate is going to be 2/3 of the actual value. Obviously this won't work well for mining as-is, but it at least it demonstrates that uint3 vectors work.

[Diapolo]

It really bothers me, the kernel you linked is one I know, it's an earlier version, who uses a different approach to compute the bases used in the kernel. Phateus introduced another method in his 2.x kernel, which I took and refined. But this seems to break uint3 support for my current version. Only other big difference I can think of is the use of an ulong as output buffer in my version, where your linked one still has an uint ... weird and it sucks ^^.

By the way, what have you added in 1.7.3? I downloaded and it works so far ... thanks.

Dia

[jedi95]

It really bothers me, the kernel you linked is one I know, it's an earlier version, who uses a different approach to compute the bases used in the kernel. Phateus introduced another method in his 2.x kernel, which I took and refined. But this seems to break uint3 support for my current version. Only other big difference I can think of is the use of an ulong as output buffer in my version, where your linked one still has an uint ... weird and it sucks ^^.

By the way, what have you added in 1.7.3? I downloaded and it works so far ... thanks.

Dia

I mainly intended to eliminate pyopencl as the source of the problem.

1.7.3 has a few fixes:
 - Updated phatk and poclbm to use bitselect() with BFI_INT disabled. This should help for GCN based GPUs (7970)
 - Modified WORKSIZE checking for poclbm, phatk, phatk2.
 - Disallowed -q 0 since it won't work correctly.

From what I have read bitselect() will properly compile to BFI_INT on GCN based GPUs without the crazy binary patching method required for VLIW5/VLIW4.

[RobertRibbeck]

It really bothers me, the kernel you linked is one I know, it's an earlier version, who uses a different approach to compute the bases used in the kernel. Phateus introduced another method in his 2.x kernel, which I took and refined. But this seems to break uint3 support for my current version. Only other big difference I can think of is the use of an ulong as output buffer in my version, where your linked one still has an uint ... weird and it sucks ^^.

By the way, what have you added in 1.7.3? I downloaded and it works so far ... thanks.

Dia

I mainly intended to eliminate pyopencl as the source of the problem.

1.7.3 has a few fixes:
 - Updated phatk and poclbm to use bitselect() with BFI_INT disabled. This should help for GCN based GPUs (7970)
 - Modified WORKSIZE checking for poclbm, phatk, phatk2.
 - Disallowed -q 0 since it won't work correctly.

From what I have read bitselect() will properly compile to BFI_INT on GCN based GPUs without the crazy binary patching method required for VLIW5/VLIW4.

Crashes for me on win7 64bit

[Diapolo]

It really bothers me, the kernel you linked is one I know, it's an earlier version, who uses a different approach to compute the bases used in the kernel. Phateus introduced another method in his 2.x kernel, which I took and refined. But this seems to break uint3 support for my current version. Only other big difference I can think of is the use of an ulong as output buffer in my version, where your linked one still has an uint ... weird and it sucks ^^.

By the way, what have you added in 1.7.3? I downloaded and it works so far ... thanks.

Dia

I mainly intended to eliminate pyopencl as the source of the problem.

1.7.3 has a few fixes:
 - Updated phatk and poclbm to use bitselect() with BFI_INT disabled. This should help for GCN based GPUs (7970)
 - Modified WORKSIZE checking for poclbm, phatk, phatk2.
 - Disallowed -q 0 since it won't work correctly.

From what I have read bitselect() will properly compile to BFI_INT on GCN based GPUs without the crazy binary patching method required for VLIW5/VLIW4.

I'm pretty sure your change to bitselect() was not needed, because it should have worked before, too . I was the one who wrote it that way.
But thanks for your hard work and the exchange we have, it's fun!

Dia

[Enigma81]

Nice Upgrade.. Excellent Work..

I finally took the time to upgrade from 1.6.2 to 1.7.3..  Nice results..

Just for example, my test rig has a single 5850 and went from 398 -> 438 MH/s.  10% !!

Enigma

[Diapolo]

@jedi95: I saw that you are using PyOpenCL version 2011.1beta3 and tried to replace cl.enqueue_read_buffer(self.commandQueue, self.output_buf, self.output) with cl.enqueue_copy(self.commandQueue, self.output_buf, self.output), because enqueue_read_buffer() and enqueue_write_buffer() are not supported anymore, at least pyOpenCL docs say "Add pyopencl.enqueue_copy(). Deprecate all other transfer functions.". Perhaps a switch to the latest PyOpenCL version can fix this + we could throw out the unsupported commands. What do you think?

I read that Vector types were added aswell, see: http://documen.tician.de/pyopencl/array.html#pyopencl.array.vec

Edit: I saw a few Reject reason: stale errors, what does this error mean?

Thanks,
Dia

[jedi95]

@jedi95: I saw that you are using PyOpenCL version 2011.1beta3 and tried to replace cl.enqueue_read_buffer(self.commandQueue, self.output_buf, self.output) with cl.enqueue_copy(self.commandQueue, self.output_buf, self.output), because enqueue_read_buffer() and enqueue_write_buffer() are not supported anymore, at least pyOpenCL docs say "Add pyopencl.enqueue_copy(). Deprecate all other transfer functions.". Perhaps a switch to the latest PyOpenCL version can fix this + we could throw out the unsupported commands. What do you think?

I read that Vector types were added aswell, see: http://documen.tician.de/pyopencl/array.html#pyopencl.array.vec

Edit: I saw a few Reject reason: stale errors, what does this error mean?

Thanks,
Dia

"Reject reason:" is sent by the pool server to indicate why a share was rejected. "stale" simply indicates that the share was from the previous block, and not useful.

The Windows binaries for Phoenix use PyOpenCL 0.92. I have tried both PyOpenCL 2011.1 and 2011.2, but for some reason they introduce a substantial delay to getting work. These versions also have a 1-2% hashrate loss compared to 0.92.

The deprecated functions are only at the API level. enqueue_copy() uses enqueue_write_buffer() and enqueue_read_buffer() internally.

If you want to make the deprecation warnings go away, just do this: (Will not work with compiled binaries, since they use 0.92)

Code:

Replace:
 cl.enqueue_read_buffer(self.commandQueue, self.output_buf, self.output)
With:
 cl.enqueue_copy(self.commandQueue, self.output, self.output_buf)

and

Replace:
 cl.enqueue_write_buffer(self.commandQueue, self.output_buf, self.output)
With:
 cl.enqueue_copy(self.commandQueue, self.output_buf, self.output)

If you want to compare versions for yourself, you can download them here: (These only work with Python 2.6)
http://jedi95.com/files/pyopencl-0.92.zip
http://jedi95.com/files/pyopencl-2011.1.zip
http://jedi95.com/files/pyopencl-2011.2.zip

[deepceleron]

The Windows binaries for Phoenix use PyOpenCL 0.92. I have tried both PyOpenCL 2011.1 and 2011.2, but for some reason they introduce a substantial delay to getting work. These versions also have a 1-2% hashrate loss compared to 0.92.

When running Dia's kernel on the 1.7.3 Win32 exe, it spits out this message:

[13/01/2012 12:58:20] using PyOpenCL version 2011.1beta3

thanks to these lines in __init__.py:

# output used pyOpenCL version
self.interface.debug('using PyOpenCL version ' + cl.VERSION_TEXT)

The hashrate loss in 2011.x is similar to what I've seen running from source, so if 1.7.3 exe has 2011.1, maybe a repackaging can get a bit more hashrate(?)

[jedi95]

The Windows binaries for Phoenix use PyOpenCL 0.92. I have tried both PyOpenCL 2011.1 and 2011.2, but for some reason they introduce a substantial delay to getting work. These versions also have a 1-2% hashrate loss compared to 0.92.

When running Dia's kernel on the 1.7.3 Win32 exe, it spits out this message:

[13/01/2012 12:58:20] using PyOpenCL version 2011.1beta3

thanks to these lines in __init__.py:

# output used pyOpenCL version
self.interface.debug('using PyOpenCL version ' + cl.VERSION_TEXT)

The hashrate loss in 2011.x is similar to what I've seen running from source, so if 1.7.3 exe has 2011.1, maybe a repackaging can get a bit more hashrate(?)

Ah, I must have missed some of the files when I was messing around with it trying to fix the delay getting work. The _cl.pyd file is from 0.92.

I have re-uploaded 1.7.3 with this fix applied. The old version of 1.7.3 has been re-uploaded as phoenix-1.7.3_old.zip.

[deepceleron]

I have re-uploaded 1.7.3 with this fix applied. The old version of 1.7.3 has been re-uploaded as phoenix-1.7.3_old.zip.

Same hashrate, using -a 100 and running for five minutes until the last digit stops changing, but the reported version is 0.98. Thanks.

[RobertRibbeck]

The Windows binaries for Phoenix use PyOpenCL 0.92. I have tried both PyOpenCL 2011.1 and 2011.2, but for some reason they introduce a substantial delay to getting work. These versions also have a 1-2% hashrate loss compared to 0.92.

When running Dia's kernel on the 1.7.3 Win32 exe, it spits out this message:

[13/01/2012 12:58:20] using PyOpenCL version 2011.1beta3

thanks to these lines in __init__.py:

# output used pyOpenCL version
self.interface.debug('using PyOpenCL version ' + cl.VERSION_TEXT)

The hashrate loss in 2011.x is similar to what I've seen running from source, so if 1.7.3 exe has 2011.1, maybe a repackaging can get a bit more hashrate(?)

Ah, I must have missed some of the files when I was messing around with it trying to fix the delay getting work. The _cl.pyd file is from 0.92.

I have re-uploaded 1.7.3 with this fix applied. The old version of 1.7.3 has been re-uploaded as phoenix-1.7.3_old.zip.

still quits after 10 sec
Its totally buggy