[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUB8ovTG=opPv4Mo5tXQ+dneHE8HdbCEHXP+JzWn_7BoUw@mail.gmail.com>
Date: Wed, 7 Oct 2015 12:46:31 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: nVidia Maxwell support (especially descrypt)?
On Wed, Oct 7, 2015 at 8:44 AM, Solar Designer <solar@...nwall.com> wrote:
> #define OVERRIDE_AUTO_CONFIG 0
> #define HARDCODE_SALT 0
> #define FULL_UNROLL 0
> #define PARALLEL_BUILD 0
>
We now have auto-selection of kernels enabled for specific devices. Both
Titan X and tahiti are configured to use harcoded-full-unrolled kenrel.
While CPU devices use basic kernel, previously selected by setting
HARDCODE_SALT to 0 and FULL_UNROLL to 0. If you'd like to manually change
config, then set the flag OVERRIDE_AUTO_CONFIG to 1 and change other
parameters as before.
IIRC, previously HARDCODE_SALT was the setting to enable this mode.
>
Previously, for best performance, we'd use HARDCODE_SALT = 1 and
FULL_UNROLL = 1 for tahiti. Setting only HARDCODE_SALT, results in much
smaller sized binaries but also looses some performance on tahiti.
PARALLEL_BUILD which I thought would be faster by large margin, isn't so.
Seems like opencl compilers are still sequential. Otherwise on our side,
this bottleneck has been eliminated.
but enabling it made the compiler crash with a
> weird error (when targeting Titan X), so maybe something isn't MT-safe.
This is new. I'll look into.
is it still possible to lazy-build during
> cracking?
>
No, it is not. But do we really need it ?
Really need documentation for this, even if it's still in development.
> And then we could proceed to discuss how to revise it to make it more
> usable.
>
Sure. We'll do.
Regards,
Sayantan
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.
