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.