Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 03 May 2012 11:36:43 -0300
From: Claudio André <>
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.


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.