[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 03 May 2012 11:36:43 -0300
From: Claudio André <claudioandre.br@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: [john-council] Defunct process on bull
Em 03-05-2012 10:54, Milen Rangelov escreveu:
> In fact there is something that we can do and that would be a
> workaround, but it's rather time-consuming. Split the kernel in
> several parts, write intermediate data to global memory. There is
> going to be an overhead from kernel launch latencies and global memory
> reads/writes, however it is not unlikely that the result would be
> somewhat faster kernel, because of the lower resource
> utilization/higher occupancy. But that is really going to change both
> kernels and the host code a lot.
>
>
> I am sure it's a driver problem, but AMD support is just
> discarding my rants (as usual).
>
> Problem is that it does not even happen with my own software
> only, other GPU crackers I've tried have the same issue and
> lock my system. OTOH, I have a NVidia card on the same system
> and the very same kernel runs with no problems on that
> platform. And I also like the way everything works perfectly
> if I castrate the NDRange to a point where occupancy drops
> unacceptably. Well good to know the root cause is not my code
> as they suggested.
>
>
> Sure we found more than one problem on AMD software. Sometimes we
> can try to avoid it, but, the others, AMD has to solve it.
>
> Meanwhile, we will keep complaining about problems in AMD OpenCL
> SDK and AMD driver.
>
> Claudio
>
It is not only time-consuming. It is frustrating to solve a fictional
problem. To "fix" correct code.
AMD has to do something.
Claudio
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.
