Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Oct 2012 19:17:32 +0200
From: magnum <>
Subject: Re: CUDA tweaking to your actual GPU

On 8 Oct, 2012, at 18:11 , Solar Designer <> wrote:

> On Mon, Oct 08, 2012 at 11:40:40AM -0400, Rick Zero_Chaos Farina wrote:
>> So can we do the same for cuda then?
> The same == what?  Several things have been mentioned.  Anyhow, I and
> others in here understand that distros want to be able to have a single
> mostly-binary build that is near-optimal for a wide range of systems.
> We do have this in mind.
>> This is what hashcat does now as well.
> As far as I'm aware, hashcat uses precompiled kernels with both OpenCL
> and CUDA - perhaps many for each hash type, yes (for different GPUs).

Why would you want precompiled kernels for a distro though? I assume Hashcat does this mostly for protecting its source code - which we do not need (nor want) to. There are obvious benefits with run-time compilation, and *especially* for distros. It was designed that way for a reason. If you'd make a "jumbo-opencl" package from our current tree, with dependecies of *any* opencl framework package(s), the end user will be able to run it even if his/her hardware (and drivers/framework) are newer than the JtR package itself.

I think we have other important tasks for distros though: Apart from the license mess... I'm not sure our current placement of OpenCL and CUDA headers and sources - in the run directory - works at all with a systemwide build. Has anyone tried that? Will they currently end up in the systemwide bin directory or in ~/.john? Will the OpenCL or CUDA program find them at all?


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.