[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50D1B2CE.3010706@gmail.com>
Date: Wed, 19 Dec 2012 10:27:58 -0200
From: Claudio André <claudioandre.br@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Opencl build from binary
Em 18-12-2012 17:39, magnum escreveu:
> On 18 Dec, 2012, at 15:39 , Claudio André <claudioandre.br@...il.com> wrote:
>> 2012/7/5 SAYANTAN DATTA <std2048@...il.com>:
>>> I want to make a patch for JtR for building opencl programs from binaries.
>>> So should I make a seperate file or should I modify the common-opencl.c ?
>>> If I am given the permission to modify the common-opencl.c, I will ensure
>>> that it doesn't create any problems for the current build.
> Is the intention to "cache" compiled kernels for later runs? Nvidida's drivers already do this, but not AMD from what I can tell.
Yes and yes. It is very useful on AMD compilation time on GPU. NVIDIA
just ignores it.
>
>> Hi, i created a new patch using this. Unfortunately, i had to change common-opencl a little. Please check if the change is acceptable.
>> - it doesn't impact or hurt legacy code.
>> - if anyone want to use it, only code inside the format xxx_fmt.c file has to be created.
>> - everything seems fine, but more tests are needed. Specially on different platforms (i mean OSX).
> I just tried applying it and built under OSX with no problems, I see no problems with committing it.
I am worried about running the binary later. It is what all closed
source software is doing now, but i had troubles in all "security"
closed source software i tried here (i tried two).
Since we build using the target machine, i suppose it is not going to be
a problem. But, who knows...
> From a quick look at opencl_cryptsha512_fmt.c in your repo, I wonder
> why you didn't make more of it shared? The format could just call
> opencl_build_kernel() and the common code could use the binary if
> available, transparent to the format. However, I guess we need some
> kind of version-control. Or is there already? I didn't look very
> closely. It could be like
Of course more can be shared. And, in this case, version control is needed.
> if (no binary) OR (timestamp of source is newer than timestamp of binary)
> build [and write/overwrite binary]
> else
> use binary
>
> Or is that too simple? I can't think of any problems with that.
This plus different binary file names (according to device name) seems
to be ok to me too.
>
>> BTW: should we move the .cl files to a new folder, e,g. "../run/kernels" and save binary files there? We have dozens of OpenCL files now.
> I had that idea too but then we'd need to ensure that system-wide builds doesn't break. And I'm too lazy to test that :-)
What do you mean by system-wide? cp john dir to /usr/bin and set PATH to
it? Use packages from, for example, http://pkgs.org <http://pkgs.org/>?
Claudio
Content of type "text/html" skipped
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.
