[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120626000434.GB11020@openwall.com>
Date: Tue, 26 Jun 2012 04:04:34 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Cc: Bit Weasil <bitweasil@...il.com>
Subject: Re: OpenCL kernel max running time vs. "ASIC hang"
On Tue, Jun 26, 2012 at 01:54:45AM +0200, magnum wrote:
> On 2012-06-26 01:27, Solar Designer wrote:
> >I understand that reducing the amount of parallelism in a kernel
> >invocation slows things down, but why not reduce the amount of work per
> >kernel invocation by other means - specifically, in your example, why
> >not reduce the number of SHA-1 iterations per kernel invocation? We may
> >invoke the kernel more than once from one crypt_all() call,
> >sequentially. For example, the 256k may be achieved by 256 invocations
> >of a kernel doing 1k iterations. This would bring the 9 seconds down to
> >35 ms per kernel invocation. Perhaps the intermediate results can even
> >stay in the GPU between those invocations.
> >
> >Have you considered that?
>
> Yes only now, and I was thinking more like 16K rounds x16.
I think we should have this configurable (at least compile-time) and
should try different values.
> Not sure I
> want to go there unless AMD says somewhere that this is actually a
> design limit. Maybe they do? I would like to know the exact specified limit.
I guess this is not documented.
Besides the "ASIC hang" risk, the kernel runtime may also need to be
tunable for optimal performance vs. good interactivity, as Bit Weasil
has pointed out.
Alexander
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.
