Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <224fa805e1c63999f5c20cc45d2d8069@smtp.hushmail.com>
Date: Fri, 21 Dec 2012 02:29:26 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Varous experimental OpenCL commits

On 20 Dec, 2012, at 20:38 , Claudio André <claudioandre.br@...il.com> wrote:
> Em 19-12-2012 23:03, magnum escreveu:
>> Claudio, Sayantan, all
>> 
>> I have committed a couple patches that are somewhat experimental:
>> 
>> 
>> 1. A patch that adds an "opencl_process_event()" function in common-opencl.c,
> Committed (sha256crypt and sha512crypt).
> 
> 
>> 3. Modifications to all my OpenCL formats so they actually use the 'count' argument passed to crypt_all() to decrease global worksize when possible. This has several good consequences: It makes Single mode work less bad (min_keys_per_crypt can be set to local worksize) and it speeds up self-test - often a lot! For example, Office 2007 benchmark took 1:45 before this patch, and just 25 seconds now.
> Committed.
> 
>> ...then replace all uses of global_work_size within the function to crypt_gws. Simple as that! Don't forget to set self->params.min_keys_per_crypt to local_work_size in init(). Actually, I set it to MAX(local_work_size, 8) because some CPU drivers will use a local_work_size of 1 and we don't want it that low.
> On AMD LWS=1 is a nice choice for slow hashes. I will try this again and (re)check.
> 
> 
> ----
> 
> Everything seems fine. These improvements seem a to be a must have in all formats!

The "gws>=count" should be easy to implement in nearly all formats. The process_event thingy requires split kernels though - of those, only Sayantan's mscash2 is lacking it after your commits reach unstable-jumbo.

OTOH most of Dhiru's formats should be converted to new split-kernel style asap. They should also auto-tune better to the device. That goes for mscash2-opencl too btw, it just kills my laptop with hard-coded Tahiti sizes.

A side-effect of the gws>=count stuff is that you can make a format better suited for weak devices by using the --mkpc option, even if there is absoultely no support for setting LWS/GWS in the format. Buffers will be created larger, but that doesn't hurt much.

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.