[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJAsdNje9QTqcibMj9RZUG2QWJehxeedU72RvR6s4ydf7RFSZA@mail.gmail.com>
Date: Thu, 5 Sep 2013 04:00:48 +0200
From: Dániel Bali <balijanosdaniel@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Daniel's weekly report #12
Hello!
2013/9/3 Solar Designer <solar@...nwall.com>
> Daniel,
>
> Yes. We already have a CRC-32 JtR format in jumbo, it works on CPU.
> You'd produce the same on GPU, using gcnasm for the GPU code, as a
> sample and a baseline for further work on JtR formats that use gcnasm.
> Since this is primarily a sample, please keep the code simple. Its
> speed is unimportant. In fact, it will certainly run slower than its
> CPU equivalent, because of all the data transfers to/from GPU (unless
> you implement mask mode on GPU, which Sayantan is working on - but you
> should not bother with that yet). We need a very basic/skeleton format
> showing how code written using gcnasm can be integrated into JtR.
>
I have a question about loading kernels from binaries.
I see that the "opencl_build_from_binary" function is responsible for this,
and it is called from "opencl_build_kernel_save". I'm not sure I understand
this part:
//Select the kernel to run.
if (!stat(path_expand(bin_name), &bin_stat) && (source_stat.st_mtime <
bin_stat.st_mtime)) {
read_kernel_source(bin_name);
opencl_build_from_binary(sequential_id);
}
Is this only used for saving binaries and not loading them?
I tried to run a format so that the binary is generated and then remove the
kernel source and it failed.
This behavior should be changed in order to load modified binaries with
custom gcnasm code, right?
Regards,
Daniel
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.
