Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 158.

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: doca on August 20, 2012, 11:52:21 PM

Testing version 0.20 on CPU Xeon E5603 @1.60GHz with 2x GPU Nvidia Quadro NVS 295 .

Running on first GPU oclvanitygen.exe -v -D 0:0 1doca

Code:

...

Running on second GPU (must be the one connected to display)

Code:

...

Running on CPU vanitygen64

Code:

vanitygen64.exe -v 1doca
Prefix difficulty: 264104224 1doca
Difficulty: 264104224
Using 4 worker thread(s)
[431.31 Kkey/s][total 5718272][Prob 2.1%][50% in 6.9min]

Running on CPU vanitygen

Code:

vanitygen.exe -v 1doca
Prefix difficulty: 264104224 1doca
Difficulty: 264104224
Using 4 worker thread(s)
[291.27 Kkey/s][total 7392256][Prob 2.8%][50% in 10.1min]

I was not expecting that Quadro NVS 295 would be so slow: 130 Kkeys/s on GPU vs. 430 Kkeys/s on CPU.

Any ideas why I got that crash on second GPU?

Hi doca,

Quadro NVS huh? You must have a fancy multi-monitor stock broker setup.

The performance you're getting from the GPU isn't too far off from what one might expect. According to the Wikipedia article, the Quadro NVS 295 is based on G98 and has 8 CUDA cores with shader clock @ 1300 MHz.

The simple formula for NVIDIA G90/GT200 devices is:

Key/s = (CUDA cores) x (Shader clock MHz) x 17

For the NVS 295, it's 177 Kkey/s, which means oclvanitygen is probably underperforming, and would benefit from tweaking.

The failure is probably because oclvanitygen is trying to allocate too much GPU memory. Try the following on your active GPU:

Code:

oclvanitygen -v -D 0:1,grid=128x128,invsize=512 1doca

To tweak performance, change the invsize value to some larger or smaller power of two. As long as the grid is large enough, there is a sweet spot for this parameter that will provide the best performance, and oclvanitygen might not be smart enough to choose it automatically.

doca

newbie

Activity: 34

Merit: 0

Testing version 0.20 on CPU Xeon E5603 @1.60GHz with 2x GPU Nvidia Quadro NVS 295 .

Running on first GPU oclvanitygen.exe -v -D 0:0 1doca

Code:

oclvanitygen.exe -v -D 0:0 1doca
Prefix difficulty: 264104224 1doca
Difficulty: 264104224
Device: Quadro NVS 295
Vendor: NVIDIA Corporation (10de)
Driver: 301.32
Profile: FULL_PROFILE
Version: OpenCL 1.0 CUDA
Max compute units: 1
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728
OpenCL compiler flags: -DPRAGMA_UNROLL -cl-nv-verbose
Loading kernel binary 326dd0c36930c6bea7602a3270b8186c.oclbin
Grid size: 1024x512
Modular inverse: 512 threads, 1024 ops each
Using OpenCL prefix matcher
GPU idle: 14.39%
[136.18 Kkey/s][total 130023424][Prob 38.9%][50% in 6.5min]

Running on second GPU (must be the one connected to display)

Code:

oclvanitygen.exe -v -D 0:1 1doca
Prefix difficulty: 264104224 1doca
Difficulty: 264104224
Device: Quadro NVS 295
Vendor: NVIDIA Corporation (10de)
Driver: 301.32
Profile: FULL_PROFILE
Version: OpenCL 1.0 CUDA
Max compute units: 1
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728
OpenCL compiler flags: -DPRAGMA_UNROLL -cl-nv-verbose
Loading kernel binary 326dd0c36930c6bea7602a3270b8186c.oclbin
Grid size: 1024x512
Modular inverse: 512 threads, 1024 ops each
Using OpenCL prefix matcher
GPU idle: 13.61%
[115.99 Kkey/s][total 2097152][Prob 0.8%][50% in 26.0min] c
lEnqueueUnmapMemObject(4): CL_INVALID_COMMAND_QUEUE
clEnqueueMapBuffer(0): CL_INVALID_COMMAND_QUEUE
clWaitForEvents(NDRange,0): CL_OUT_OF_RESOURCES
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_INVALID_COMMAND_QUEUE error executing CL_COMMAND_UNMAP_MEM_OBJECT on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).
vg_ocl_context_callback error: CL_OUT_OF_RESOURCES error waiting for idle on Quadro NVS 295 (Device 0).

Running on CPU vanitygen64

Code:

vanitygen64.exe -v 1doca
Prefix difficulty: 264104224 1doca
Difficulty: 264104224
Using 4 worker thread(s)
[431.31 Kkey/s][total 5718272][Prob 2.1%][50% in 6.9min]

Running on CPU vanitygen

Code:

vanitygen.exe -v 1doca
Prefix difficulty: 264104224 1doca
Difficulty: 264104224
Using 4 worker thread(s)
[291.27 Kkey/s][total 7392256][Prob 2.8%][50% in 10.1min]

I was not expecting that Quadro NVS 295 would be so slow: 130 Kkeys/s on GPU vs. 430 Kkeys/s on CPU.

Any ideas why I got that crash on second GPU?

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Version 0.20 has been released. Improvements include:

Oclvanitygen and oclvanityminer are now able to control multiple GPUs.
This makes it simpler to manage oclvanitygen on systems with multiple GPUs. To do this, you must use the new -D command line option, once for each GPU, and must specify the OpenCL platform ID and device ID for each GPU. Example, for a mining system with three GPUs:

Code:

$ ./oclvanitygen -D 0:0 -D 0:1 -D 0:2 1MuLtiGPU

On a system with multiple GPUs, running oclvanitygen 1 or otherwise not specifying a device will cause it to display a list of OpenCL devices. This list can be used to find the platform/device IDs.

Multiple pattern input files supported
It's now possible to search for case-sensitive and case-insensitive prefixes concurrently. Put each type in a separate file, and do something like:
Code:
$ ./vanitygen -f casesensitive.txt -i -f caseinsensitive.txt
Bug fixes
Crash in vanitygen with -X option (thanks forum user foo)
Case-insensitive search for prefixes containing I, O, and l should work now (thanks deepceleron)
Oclvanitygen should now display the address correctly with -X option
Oclvanityminer can now follow HTTP redirections
Oclvanityminer is now able to group together bounties by public key.
This will be important in the future, when vanity pool gets more attention. Bounties with the same public key are now processed concurrently, just like specifying multiple prefixes to oclvanitygen. The economics of this are also taken into account when choosing a bounty or set of bounties.

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: midnightlightning on August 17, 2012, 01:21:55 PM

Grids of 256x256, 128x128, and 32x32 all segfault in the same way as the original:

So that didn't work, but at least now we can feel confident that it's not simply trying to allocate too much global memory. Yet something certainly seems to be broken with resource allocation and clEnqueueMapBuffer().

I made some improvements to the error handling code in the git repository. Please pull and try again. It shouldn't segfault any more, and should give a more useful message at the end.

There are two other boilerplate things you can try: Safe mode (-S) and OpenCL verification mode (-V).

Code:

./oclvanitygen -d0 -v -S -b 128 -g 256x256 -i 1test

Quote from: unclemantis on August 17, 2012, 12:20:24 AM

This doesn't work for vanitygen-0.19-win

Quote from: unclemantis on August 17, 2012, 01:27:44 PM

It crashes on a DLL.

Perhaps I will try the LINUX version

Thank you for the help!

Interesting, which DLL does it complain about? Did you ever get it to work on Windows?

unclemantis

member

Activity: 98

Merit: 10

(:firstbits => "1mantis")

Quote from: midnightlightning on August 17, 2012, 01:21:55 PM

Quote from: unclemantis on August 17, 2012, 12:20:24 AM

Try the following command line:

Code:

./oclvanitygen -d0 -v -b 128 -g 256x256 -i 1test

If it works, try increasing the grid size, maybe -g 512x512 or -g 512x1024, but stick to powers of two. If it doesn't work, try an even smaller grid, maybe -g 128x128. To tweak the performance, try different modular inverse batch sizes, maybe -b 64 or -b 32. Also stick to powers of two for that value.

Grids of 256x256, 128x128, and 32x32 all segfault in the same way as the original:

Code:

$ ./oclvanitygen -d0 -v -b 128 -g 32x32 -i 1test
Prefix difficulty: 17606948 1test
Difficulty: 17606948
Device: GeForce GT 120
Vendor: NVIDIA (1022600)
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0
Max compute units: 4294967300
Max workgroup size: 512
Global memory: 536870912
Max allocation: 134217728
OpenCL compiler flags: -DDEEP_PREPROC_UNROLL
Loading kernel binary 2883e067f0d6d3d9b75e3f670239ca65.oclbin
Grid size: 32x32
Modular inverse: 8 threads, 128 ops each
Using OpenCL prefix matcher
vg_ocl_context_callback error: [CL_OUT_OF_RESOURCES] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Out of resources

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Finish caused an error that invalidated the queue (0x10041d070). This may be due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clCommandDispatch failed: flushing queue for blocking call.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueMapBuffer failed: Invalid command queue
clEnqueueMapBuffer(0): CL_INVALID_COMMAND_QUEUE
Segmentation fault

It crashes on a DLL.

Perhaps I will try the LINUX version

Thank you for the help!

midnightlightning

member

Activity: 68

Merit: 10

Quote from: unclemantis on August 17, 2012, 12:20:24 AM

Try the following command line:

Code:

./oclvanitygen -d0 -v -b 128 -g 256x256 -i 1test

If it works, try increasing the grid size, maybe -g 512x512 or -g 512x1024, but stick to powers of two. If it doesn't work, try an even smaller grid, maybe -g 128x128. To tweak the performance, try different modular inverse batch sizes, maybe -b 64 or -b 32. Also stick to powers of two for that value.

Grids of 256x256, 128x128, and 32x32 all segfault in the same way as the original:

Code:

$ ./oclvanitygen -d0 -v -b 128 -g 32x32 -i 1test
Prefix difficulty: 17606948 1test
Difficulty: 17606948
Device: GeForce GT 120
Vendor: NVIDIA (1022600)
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0
Max compute units: 4294967300
Max workgroup size: 512
Global memory: 536870912
Max allocation: 134217728
OpenCL compiler flags: -DDEEP_PREPROC_UNROLL
Loading kernel binary 2883e067f0d6d3d9b75e3f670239ca65.oclbin
Grid size: 32x32
Modular inverse: 8 threads, 128 ops each
Using OpenCL prefix matcher
vg_ocl_context_callback error: [CL_OUT_OF_RESOURCES] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Out of resources

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Finish caused an error that invalidated the queue (0x10041d070). This may be due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clCommandDispatch failed: flushing queue for blocking call.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueMapBuffer failed: Invalid command queue
clEnqueueMapBuffer(0): CL_INVALID_COMMAND_QUEUE
Segmentation fault

unclemantis

member

Activity: 98

Merit: 10

(:firstbits => "1mantis")

Quote from: samr7 on August 16, 2012, 07:14:50 PM

Quote from: midnightlightning on August 16, 2012, 04:38:21 PM

Here's the full output; it doesn't seem to do any calculation before segfaulting:

Code:

...

Though if your "back of the napkin" calculations are right, I get the same rate (600 Kkey/s) from using 16 threads on the two quad-core 2.26 GHz Xeons I've got in this Mac, so probably a moot point to get it working on the GPU.

As I mentioned, I have gotten GPU miners running on this machine, and they pull around 5 Megahashes/second. Is the address generation that much more complex that it gets one-tenth the speed (600 KKey/s ~= 0.6 MKey/s)?

Hi midnightlightning,

I see, so it's not even getting started.

Try the following command line:

Code:

./oclvanitygen -d0 -v -b 128 -g 256x256 -i 1test

If it works, try increasing the grid size, maybe -g 512x512 or -g 512x1024, but stick to powers of two. If it doesn't work, try an even smaller grid, maybe -g 128x128. To tweak the performance, try different modular inverse batch sizes, maybe -b 64 or -b 32. Also stick to powers of two for that value.

Oclvanitygen will try to automatically determine the best values for those parameters. It's a hack right now that has only been tested extensively on large discrete GPUs with lots of dedicated memory. It would make sense for it to get them wrong, and the whole mechanism might need to be re-examined.

Quote from: unclemantis on August 16, 2012, 04:39:14 PM

Can we add the method for generating public addresses starting with the number 3 as well as 1?

Hi unclemantis,

This feature is implemented, but it's limited right now. Here's a usage example:

Code:

$ ./vanitygen -F script 3Love
Difficulty: 4553521
Pattern: 3Love
P2SHAddress: 3Love2U8TrDhNZvdvNa5akVcizP2jNi7t5
Address: 1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe
Privkey: 5JE2zrTLBUXNi8Rz7QVjNRj4r45Ghvqc7w2nVJHf1sHCVW9Qiw8

You can go ahead and import this private key, but you'll only get the 1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe address in your address book, not the one that starts with the 3. The next step is to select Help -> Debug Window, select the Console tab, and enter the following command:

Code:

addmultisigaddress 1 [\"1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe\"]

(Yes, enter it verbatim including the backslashes)

Then you'll get the 3- address in your address book and can receive coins on it.

Make sense?

Currently oclvanitygen can't search for script addresses. Also, in the future it may become possible to generate script addresses substantially faster by using embedded nonces, to the point that one can find 3- addresses with a few more characters of prefix than 1- addresses.

This doesn't work for vanitygen-0.19-win

TYDIRocks

full member

Activity: 213

Merit: 100

Yup I have released the program here: https://bitcointalksearch.org/topic/add-new-address-private-key-easily-101161 (no means of hijacking your thread samr7)

BkkCoins

hero member

Activity: 784

Merit: 1009

firstbits:1MinerQ

Quote from: TYDIRocks on August 16, 2012, 08:58:23 PM

Thanks, do you think this section is the appropriate place to post it?

Probably, I guess. If not then it may get moved. You may want to start in the general discussion board as it's probably not very technical and of more general user interest. And if the mods don't like it there they'll move it here. But more people will notice it there. Either way we shouldn't continue in this thread.

TYDIRocks

full member

Activity: 213

Merit: 100

Quote from: BkkCoins on August 16, 2012, 07:59:00 PM

Quote from: TYDIRocks on August 16, 2012, 07:42:23 PM

I created a quick little app in .Net to import private keys without having to enter console commands since the current bitcoin-qt version doesn't have a debug window. Is anyone interested or should I just keep this to myself? :p

If it is easy to use then many people would love that. See this thread over here,

https://bitcointalksearch.org/topic/bitcoin-client-redeam-private-key-92080

Someone wanting an easy way to import private keys. You might want to create your own thread explaining how to use it and then direct him to yours to try it. You should probably do something to give confidence it's not a trojan as otherwise people should be leary.

Thanks, do you think this section is the appropriate place to post it?

BkkCoins

hero member

Activity: 784

Merit: 1009

firstbits:1MinerQ

Quote from: TYDIRocks on August 16, 2012, 07:42:23 PM

I created a quick little app in .Net to import private keys without having to enter console commands since the current bitcoin-qt version doesn't have a debug window. Is anyone interested or should I just keep this to myself? :p

If it is easy to use then many people would love that. See this thread over here,

https://bitcointalksearch.org/topic/bitcoin-client-redeam-private-key-92080

Someone wanting an easy way to import private keys. You might want to create your own thread explaining how to use it and then direct him to yours to try it. You should probably do something to give confidence it's not a trojan as otherwise people should be leary.

TYDIRocks

full member

Activity: 213

Merit: 100

I created a quick little app in .Net to import private keys without having to enter console commands since the current bitcoin-qt version doesn't have a debug window. Is anyone interested or should I just keep this to myself? :p

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: midnightlightning on August 16, 2012, 04:38:21 PM

Here's the full output; it doesn't seem to do any calculation before segfaulting:

Code:

...

Though if your "back of the napkin" calculations are right, I get the same rate (600 Kkey/s) from using 16 threads on the two quad-core 2.26 GHz Xeons I've got in this Mac, so probably a moot point to get it working on the GPU.

As I mentioned, I have gotten GPU miners running on this machine, and they pull around 5 Megahashes/second. Is the address generation that much more complex that it gets one-tenth the speed (600 KKey/s ~= 0.6 MKey/s)?

Hi midnightlightning,

I see, so it's not even getting started.

Try the following command line:

Code:

./oclvanitygen -d0 -v -b 128 -g 256x256 -i 1test

If it works, try increasing the grid size, maybe -g 512x512 or -g 512x1024, but stick to powers of two. If it doesn't work, try an even smaller grid, maybe -g 128x128. To tweak the performance, try different modular inverse batch sizes, maybe -b 64 or -b 32. Also stick to powers of two for that value.

Oclvanitygen will try to automatically determine the best values for those parameters. It's a hack right now that has only been tested extensively on large discrete GPUs with lots of dedicated memory. It would make sense for it to get them wrong, and the whole mechanism might need to be re-examined.

Quote from: unclemantis on August 16, 2012, 04:39:14 PM

Can we add the method for generating public addresses starting with the number 3 as well as 1?

Hi unclemantis,

This feature is implemented, but it's limited right now. Here's a usage example:

Code:

$ ./vanitygen -F script 3Love
Difficulty: 4553521
Pattern: 3Love
P2SHAddress: 3Love2U8TrDhNZvdvNa5akVcizP2jNi7t5
Address: 1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe
Privkey: 5JE2zrTLBUXNi8Rz7QVjNRj4r45Ghvqc7w2nVJHf1sHCVW9Qiw8

You can go ahead and import this private key, but you'll only get the 1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe address in your address book, not the one that starts with the 3. The next step is to select Help -> Debug Window, select the Console tab, and enter the following command:

Code:

addmultisigaddress 1 [\"1LFUpSr7qTXjtvJowCnD19tu8tBVKUXaRe\"]

(Yes, enter it verbatim including the backslashes)

Then you'll get the 3- address in your address book and can receive coins on it.

Make sense?

Currently oclvanitygen can't search for script addresses. Also, in the future it may become possible to generate script addresses substantially faster by using embedded nonces, to the point that one can find 3- addresses with a few more characters of prefix than 1- addresses.

unclemantis

member

Activity: 98

Merit: 10

(:firstbits => "1mantis")

Can we add the method for generating public addresses starting with the number 3 as well as 1?

midnightlightning

member

Activity: 68

Merit: 10

Quote from: samr7 on August 15, 2012, 07:44:24 PM

Sorry to hear it's having issues on your Mac.

How long did it run before you got this error message? Did it make any progress?

Try running it with -v to get verbose output.

I think you're right about it in this case. A back-of-the-napkin calculation suggests that a GeForce GT 120M @ 500Mhz with 32 CUDA cores should be capable of an upper bound of 650 Kkey/s.

Here's the full output; it doesn't seem to do any calculation before segfaulting:

Code:

$ ./oclvanitygen -d0 -v -i 1test
Prefix difficulty: 17606948 1test
Difficulty: 17606948
Device: GeForce GT 120
Vendor: NVIDIA (1022600)
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0
Max compute units: 4294967300
Max workgroup size: 512
Global memory: 536870912
Max allocation: 134217728
OpenCL compiler flags: -DDEEP_PREPROC_UNROLL
Loading kernel binary 2883e067f0d6d3d9b75e3f670239ca65.oclbin
Grid size: 1024x1024
Modular inverse: 2048 threads, 512 ops each
Using OpenCL prefix matcher
vg_ocl_context_callback error: [CL_OUT_OF_RESOURCES] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Out of resources

vg_ocl_context_callback error: [CL_OUT_OF_RESOURCES] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Out of resources

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_KERNEL] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid kernel object

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Finish caused an error that invalidated the queue (0x10ab10620). This may be due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clCommandDispatch failed: flushing queue for blocking call.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueMapBuffer failed: Invalid command queue
clEnqueueMapBuffer(0): CL_INVALID_COMMAND_QUEUE
Segmentation fault

Though if your "back of the napkin" calculations are right, I get the same rate (600 Kkey/s) from using 16 threads on the two quad-core 2.26 GHz Xeons I've got in this Mac, so probably a moot point to get it working on the GPU.

As I mentioned, I have gotten GPU miners running on this machine, and they pull around 5 Megahashes/second. Is the address generation that much more complex that it gets one-tenth the speed (600 KKey/s ~= 0.6 MKey/s)?

samr7

full member

Activity: 140

Merit: 430

Firstbits: 1samr7

Quote from: midnightlightning on August 13, 2012, 10:05:16 AM

I've got an OpenCL error running oclvanitygen on a Mac (NVIDIA Geforce GT 120):

Code:

...

A "Failed to wait for events" error; is this an OSX-specific OpenCL error, or have others run into this? How can I diagnose what is going wrong here?

Hi midnightlightning,

Sorry to hear it's having issues on your Mac.

How long did it run before you got this error message? Did it make any progress?

Try running it with -v to get verbose output.

Unfortunately, I do not have any Apple hardware to test with, let alone do performance tuning. Also, as near as I can tell, Apple has their own OpenCL stack that differs substantially from what one might find in the Catalyst or nVidia drivers on Windows/Linux. So, you've hit kind of a sore spot right now.

Quote from: ErebusBat on August 13, 2012, 11:29:06 AM

My guess is that the kernel is only for AMD and the NVIDIA architecture isn't ideal for this kind of thing.

I think you're right about it in this case. A back-of-the-napkin calculation suggests that a GeForce GT 120M @ 500Mhz with 32 CUDA cores should be capable of an upper bound of 650 Kkey/s.

However, for the record, primary development work on the vanitygen OpenCL kernel has been done using a high-end nVidia card. It runs a lot faster on AMD hardware, but the nVidia platform doesn't receive any less attention for that reason.

ErebusBat

hero member

Activity: 560

Merit: 500

I am the one who knocks

Quote from: midnightlightning on August 15, 2012, 12:21:28 PM

Agreed, but "isn't ideal" shouldn't equal "impossible"; I've got GPU-based miners running nicely on this machine, and I have seen previously in the thread other Mac users able to use their NVIDIA cards (so it's not "only AMD", though they had errors if they had a very low worksize parameter). Even if it's not ideal, I should be able to do better than the 600 Kkey/s I get with CPU processing of vanitygen on this box.

I can program in several languages, but OpenCL isn't one of them, so I have no idea where to start troubleshooting. Anyone with OpenCL experience able to tell me where I should start trying to solve this?

It isn't impossible, it is just that no one has written a kernel for it. Infact it is my understanding that nvidia performs so badly in this type of operation that work was abandoned on it years ago. But I am not a miner and I could be wrong.

Here is a couple of links I found:
http://www.drdobbs.com/parallel/a-gentle-introduction-to-opencl/231002854
http://bit.ly/rEhjyO

midnightlightning

member

Activity: 68

Merit: 10

Quote from: ErebusBat on August 13, 2012, 11:29:06 AM

Quote from: midnightlightning on August 13, 2012, 10:05:16 AM

I've got an OpenCL error running oclvanitygen on a Mac (NVIDIA Geforce GT 120):

A "Failed to wait for events" error; is this an OSX-specific OpenCL error, or have others run into this? How can I diagnose what is going wrong here?

My guess is that the kernel is only for AMD and the NVIDIA architecture isn't ideal for this kind of thing.

Agreed, but "isn't ideal" shouldn't equal "impossible"; I've got GPU-based miners running nicely on this machine, and I have seen previously in the thread other Mac users able to use their NVIDIA cards (so it's not "only AMD", though they had errors if they had a very low worksize parameter). Even if it's not ideal, I should be able to do better than the 600 Kkey/s I get with CPU processing of vanitygen on this box.

I can program in several languages, but OpenCL isn't one of them, so I have no idea where to start troubleshooting. Anyone with OpenCL experience able to tell me where I should start trying to solve this?

dree12

legendary

Activity: 1246

Merit: 1077

Quote from: BurtW on August 13, 2012, 09:57:29 PM

Now this is strange. When I tried some things work, some do not:

C:\downloads\www.bitcoin.org>vanitygen -F script 3Biteme

BUT 3Test does not work

BUT 3biteme does NOT work

BUT 3Biteme does work, etc.

Certain things work, others do not

Can someone explain this to me?

Answered this in your other thread, but I'll repeat here.

The version "5" covers only the first half of 3-prefixed addresses. The rest are in version "6", with some confined to versions "4" and "7".

BurtW

legendary

Activity: 2646

Merit: 1137

All paid signature campaigns should be banned.

Now this is strange. When I tried some things work, some do not:

C:\downloads\www.bitcoin.org>vanitygen -F script 3Biteme

BUT 3Test does not work

BUT 3biteme does NOT work

BUT 3Biteme does work, etc.

Certain things work, others do not

Can someone explain this to me?

Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 158. (Read 1153383 times)