Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 22 Dec 2012 10:19:32 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Opencl build from binary

On Fri, Dec 21, 2012 at 1:21 AM, 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?
> Are we going to create more threads to control (each) device crypt_all?
>
> Claudio
>

At first when I tried pthreads for controlling each device but for some
reason opencl did not behave as expected. I guess opencl 1.0 specs does not
support multiple threads for scheduling multiple devices. However you can
initialize all the devices within the context , then
use separate  command ques, kernel objects and program objects for multiple
devices.Then enque the kernels and wait for all of them to finish. You will
want all your kernels to finish execution at same time. So distribute the
work accordingly.

Yes it would be a nice idea to support --devices = 1,2,3...., but I think
we should internally map the device numbers to corresponding pairs of
platform_number and device_number inside common-opencl.c .

Regards,
Sayantan

[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ