Why POCLBM Gives Errors Without -v In Place?

[gigabytecoin]

I was just pulling my hair out for a few minutes because all of my cards were showing the dreaded "verification failed, check hardware" on the command line interface after just a few seconds of mining.

Thank goodness grinder made this post here: http://bitcointalk.org/index.php?topic=1334.msg97772#msg97772

I added -v (vectors) to my poclbm variables and it began to generate flawlessly. Going on 20 minutes now with no "verification failed" messages (fingers crossed!).

Can anybody explain to me what exactly "vectors" are? Am I still using the BFI_INT calculations with vectors on? (I am using the latest POCLBM version which I believe calculates BFI_INT now as well?)

[jedi95]

I was just pulling my hair out for a few minutes because all of my cards were showing the dreaded "verification failed, check hardware" on the command line interface after just a few seconds of mining.

Thank goodness grinder made this post here: http://bitcointalk.org/index.php?topic=1334.msg97772#msg97772

I added -v (vectors) to my poclbm variables and it began to generate flawlessly. Going on 20 minutes now with no "verification failed" messages (fingers crossed!).

Can anybody explain to me what exactly "vectors" are? Am I still using the BFI_INT calculations with vectors on? (I am using the latest POCLBM version which I believe calculates BFI_INT now as well?)

With vectors enabled each thread on the GPU runs 2 hashes instead of 1. This improves performance on ATI hardware because it gives the compiler more opportunities to extract ILP (Instruction-level parallelism) compared with only running a single hash.

The latest poclbm always uses BFI_INT on ATI/AMD hardware if cl_amd_media_ops is detected. I am not sure why enabling vectors can "fix" the problem when all it does is run 2 hashes per thread on the GPU instead of 1. This may be a problem with poclbm's BFI_INT patcher, which I haven't looked at in detail yet. I don't think the OpenCL kernel itself is the problem because as m0mchil mentioned it is virtually identical to the OpenCL kernel used in Phoenix now. I have yet to see any users have this problem without vectors on Phoenix though, which is why I suspect the BFI_INT patching code.

That said, vectors should be faster on most ATI hardware anyway, so this shouldn't be a problem for the majority of users.

[gigabytecoin]

I was just pulling my hair out for a few minutes because all of my cards were showing the dreaded "verification failed, check hardware" on the command line interface after just a few seconds of mining.

Thank goodness grinder made this post here: http://bitcointalk.org/index.php?topic=1334.msg97772#msg97772

I added -v (vectors) to my poclbm variables and it began to generate flawlessly. Going on 20 minutes now with no "verification failed" messages (fingers crossed!).

Can anybody explain to me what exactly "vectors" are? Am I still using the BFI_INT calculations with vectors on? (I am using the latest POCLBM version which I believe calculates BFI_INT now as well?)

With vectors enabled each thread on the GPU runs 2 hashes instead of 1. This improves performance on ATI hardware because it gives the compiler more opportunities to extract ILP (Instruction-level parallelism) compared with only running a single hash.

The latest poclbm always uses BFI_INT on ATI/AMD hardware if cl_amd_media_ops is detected. I am not sure why enabling vectors can "fix" the problem when all it does is run 2 hashes per thread on the GPU instead of 1. This may be a problem with poclbm's BFI_INT patcher, which I haven't looked at in detail yet. I don't think the OpenCL kernel itself is the problem because as m0mchil mentioned it is virtually identical to the OpenCL kernel used in Phoenix now. I have yet to see any users have this problem without vectors on Phoenix though, which is why I suspect the BFI_INT patching code.

That said, vectors should be faster on most ATI hardware anyway, so this shouldn't be a problem for the majority of users.

Thank you for the very detailed response, jedi!

If it is possible to run 2 hashes instead of 1, why not 3 or 100 hashes instead of 1?

I noticed that my first GPU miner seemed to work (without vectors) just until I began running the second GPU miner. Then the first miner shut down and the second one did soon afterwards.

[jedi95]

Thank you for the very detailed response, jedi!

If it is possible to run 2 hashes instead of 1, why not 3 or 100 hashes instead of 1?

I noticed that my first GPU miner seemed to work (without vectors) just until I began running the second GPU miner. Then the first miner shut down and the second one did soon afterwards.

The reason you can't run run an unlimited number of hashes per thread is the number of available GPRs. (general purpose registers) At some point the bottleneck shifts from ALU operations to GPR availability, and you end up with reduced performance.