[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130702164727.GB29097@openwall.com>
Date: Tue, 2 Jul 2013 20:47:27 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bug: GPU use in CPU-only formats
On Tue, Jul 02, 2013 at 11:53:31AM -0300, Claudio Andr? wrote:
> Ok, it is possible to get all the OpenCL information needed (e.g. to
> parse the -dev option) and release everything GPU related.
Can't we separate parsing of the platform/device options from actual
processing of the parsed values - that is, postpone checking whether the
specified device even exists until we reach the format's init()?
Also, when no platform/device options are specified, so the default
device would be used, do we need to do any checking before we reach
init(), and if so - why?
> After that,
> reopen GPU stuff during init() only when needed. As it is now, every
> OpenCL enabled build could cause drivers to keep some memory allocated
> while JtR is running, even a non-GPU format
>
> BUT: no real GPU memory allocation is done inside common code. Neither
> code execution. So, ghosts and busy devices could not happen.
Somehow the NVIDIA card and the PSU actually get hotter because of this;
I wonder what's going on in there if not code execution. I think it's
at least 100W extra (roughly half-load on the card), compared to running
a CPU-only build with the same format.
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.
