[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <36dcabc9778800d160166cc0a8e0b65c@smtp.hushmail.com>
Date: Mon, 8 Oct 2012 20:17:58 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: CUDA tweaking to your actual GPU
On 8 Oct, 2012, at 19:43 , Rick Zero_Chaos Farina <zerochaos@...too.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/08/2012 01:17 PM, magnum wrote:
>> On 8 Oct, 2012, at 18:11 , Solar Designer <solar@...nwall.com> 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 recall seeing some sm_10 or something in the sources suggesting to
> change to 20 or 30 or whatever depending on hardware. Please don't
> shoot me if I'm wrong, I freely admit I'm not looking right now but I
> bet you know what I'm talking about.
Right, sorry, I was talking about OpenCL. For CUDA we could build the three main archs (or more) but OTOH my little test indicated it's not that important. I believe it's more important to use run-time configuration of blocks/threads but this will also mean the kernels might not be unrolled, or otherwise optimized by the compiler, as well as they are now. So this could mean a trade off.
>> 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?
> *.cl ends up in /etc and john finds it fine. Gentoo has been shipping
> opencl/cuda enabled jtr since it was released.
Great! I did not think it would work at all, lol.
magnum
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.
