|
|
Message-ID: <f561a50b3337193fc9d375d8286e4b2e@smtp.hushmail.com>
Date: Wed, 3 Oct 2012 02:37:24 +0200
From: magnum <john.magnum@...hmail.com>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: Response during OpenCL sessions
Solar,
Now that we start to get split kernels with much shorter durations, I wonder if/how we could react to some events between the kernel calls without a lot of work. I thought it could be as simple as this pseudo code "patch":
void crypt_all(int count)
{
enqueue(Transfer);
enqueue(RarInitKernel);
for (i=0; i<HASH_LOOPS; i++)
{
enqueue(RarLoopKernel);
+ if (event_pending)
+ process_event();
}
enqueue(RarFinalKernel);
I tried the above, using a process_event() similar to the one in cracker.c but somehow it only works during self-test (one that preceeds a crack, not a benchmark), not during actual crack. Should I call something else first? Can it not be done this way? I thought signals and timers would work fine just with this.
If we could just get a status line swiftly after a keypress (or signal), the perception that JtR hangs will go away almost completely.
BTW, just committed: The RAR OpenCL kernel is finally split into quicker subkernels. Wasn't easy and it's still a bit slow (though it got a little boost with this new code). It even has a special limit for HD7970 at 200 ms now :)
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.