[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120218153120.GA13268@openwall.com>
Date: Sat, 18 Feb 2012 19:31:20 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: format names for GPU-enabled implementations (was: Recent github patches)
On Sat, Feb 18, 2012 at 04:19:17PM +0100, magnum wrote:
> On 02/17/2012 09:22 PM, Solar Designer wrote:
> > On Fri, Feb 17, 2012 at 07:32:19PM +0100, Lukas Odzioba wrote:
> >> 1.7.9-jumbo-5-cuda-1.diff patch is on wiki.
> >> It adds support for the following fromats:
> >> phpass, cryptmd5, cryptsha256, cryptsha512, mscash, mscash2,
> >> rawsha256, rawsha224
> >
> > magnum - please merge this in your tree.
>
> Done. I presume an additional make target could combine CUDA and OpenCL
> so we get both in one build (perhaps called linux-x86-64-gpu). ??ukasz or
> Samuele, could you do this?
I leave your question/request for Lukas and/or Samuele, but here's a
related thought: right now, the GPU patches use separate format names
for hashes that are also supported on CPU, so the same build can have
both (and even several GPU implementations at once, as you suggest).
This is nice, but I suspect that many users will be confused - if they
build using a GPU-enabled make target, they expect the GPU code to be
used by default (if available for a given hash type at all). Should we
possibly make this so? And how do we also keep the CPU and alternate
GPU code compiled in (and available for use as non-default), then?
Rename those other formats?
Alternatively, should we possibly keep things as they are, but improve
documentation? Maybe have "make" runs with GPU-enabled targets end with
a note to the user on how to actually access the GPU functionality -
very brief instructions and/or a reference to a file like doc/GPU?
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.
