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.