[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 Dec 2012 21:28:18 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Opencl build from binary
On 20 Dec, 2012, at 20:51 , Claudio André <claudioandre.br@...il.com> wrote:
> Em 19-12-2012 17:28, magnum escreveu:
>> I have committed this. I think we should take this opportunity to think about another thing now that we hack around in there anyway: How can we support using multiple devices? Sayantan's mscash2 supports multiple devices already, but only by hacking the format source. We should add proper support using --platform and --device.
>>
>> Maybe we should drop the --platform notation though? On Bull (where nvidia is device #0), that would mean the Tahiti would become device #1 instead of "platform 1, device 0" and the CPUs would become device #2.
>> And maybe we should start from 1 instead - I think Hashcat would list them as device 1 and 2 with no platform notation.
>>
>> Having done that, the syntax for multiple devices becomes much easier. You could say --device=1 or --device=1,2 and perhaps even ranges like --device=1-8 for vcl use. If we wanted to we could also support types, so --device=gpus would mean "use all available GPU devices".
>>
>> That's for the options syntax. Now, how would a format use this, or know about this? Should we support using a group of heterogenous devices? What would a well thought out interface to common-opencl.c look like?
>
> Very nice resource to have. I volunteer to help.
>
> - What kind of problems Sayantan faced?
His format seem to work fine, except it doesn't have support from common-opencl.c so you need to edit it and un-comment some lines in init() to make it use more than one device. The mscash2-opencl format does 103003 c/s on 7970 or 31679 c/s on the 570. If you just do this...
diff --git a/src/opencl_mscash2_fmt.c b/src/opencl_mscash2_fmt.c
index 04cb249..d62d50a 100644
--- a/src/opencl_mscash2_fmt.c
+++ b/src/opencl_mscash2_fmt.c
@@ -205,10 +205,10 @@ static void init(struct fmt_main *self)
memset(dcc2_hash_host,0,4*sizeof(cl_uint)*MAX_KEYS_PER_CRYPT);
- select_device(platform_id,ocl_gpu_id);
+ //select_device(platform_id,ocl_gpu_id);
///Select devices select_device(int platform_no, int device_no). You may select multiple devices for faster cracking spped. Please See common_opencl_pbkdf2.h
- //select_device(1,0);
- //select_device(0,0);
+ select_device(1,0);
+ select_device(0,0);
///select default platform=0 and default device=0
//select_default_device();
...it will use both, and do 127563 c/s, which is 95% of the single-figures added together. I bet it's better if you use two or more devices of the same model.
I think common-opencl.c is half-heartedly prepared to handle several devices - for instance, device[] and queue[] and such things are arrays already. But someone need to digest it and add the missing pieces (and modify some of the existing).
> Are we going to create more threads to control (each) device crypt_all?
Maybe later, I'm not sure. But it's not really needed for slow formats like this. You can either just enqueue jobs for several devices in one go, or juggle them.
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
