Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Dec 2012 01:53:27 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Response during OpenCL sessions

On 19 Dec, 2012, at 0:24 , magnum <john.magnum@...hmail.com> wrote:
> I revisited this issue and now I got it, it's totally obvious in hindsight: That loop merely enqueues all the kernel calls, very quickly. Later, in the final, blocking, clEnqueueReadBuffer() call, nearly all of the actual execution happens. And at that point I did not have any event checks (well I couldn't, that single call blocks for 5-20 seconds while the queue finishes).
> 
> The code would need to look something like this, unless someone can think of a better solution:
> 
>  void crypt_all(int count)
>  {
>  	enqueue(Transfer);
>  	enqueue(RarInitKernel);
>  	for (i=0; i<HASH_LOOPS; i++)
>  	{
>  		enqueue(RarLoopKernel);
> +  		clFinish();
> +  		if (event_pending)
> +  			process_event();
>  	}
>  	enqueue(RarFinalKernel);
> 
> This works like a champ - but has a slight performance impact. For wpapsk on Tahiti, speed 

It seems it actually does not work on Bull, regardless of GPU used. The status is still delayed until crypt_all() has finished, as if the clFinish() was optimised away.

On my OSX laptop, I get status output within one second, using the exact same code. What could be the reason it does not work on Bull? I think I'll reboot my laptop into Linux and see what happens...

magnum


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ