|
Message-ID: <CALaL1qBeN-J1YJfMfKtU08rPZ4u1nNicgCXNiYLe8i4_WOnemw@mail.gmail.com>
Date: Tue, 26 Jun 2012 08:59:34 -0700
From: Bit Weasil <bitweasil@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: OpenCL kernel max running time vs. "ASIC hang"
I definitely agree that it didn't happen with older driver versions, which
is part of my belief that it is something with the drivers, and not
something with the code specifically. The other possibility is that the
drivers got pickier, and something that used to be out of bounds but not
specifically causing a crash now causes a crash. Of course, there's no
useful debugging.
I still don't see the problem with keeping intermediate data in global
memory. :) I guess I'm "lucky" in that I had to deal with this problem
very early on with my rainbow tables, and have gotten comfortable with the
concept/have gotten good at doing it.
This is part of the reason that, even though they're slower, I prefer
nVidia. They *just work* - it seems I spend more time tracking down weird
issues with AMD than I do coding for nVidia.
On Tue, Jun 26, 2012 at 8:19 AM, Milen Rangelov <gat3way@...il.com> wrote:
> Hello Bitweasil,
>
> Generally the same for me - increasing NDRange increases the chance I
> trigger an ASIC hang. Also it is a fact I did not trigger it with older
> driver versions. Yet even with much smaller NDRanges I can occasionally hit
> the problem, it just takes more time to reproduce. And this happens for me
> just for a specific type of kernels that involve loops and lots of memory
> accesses. In fact I have kernels that may take longer to execute (e.g
> sha512 as opposed to "old" zip encryption) but they do not cause ASIC hangs
> (at least not noticed any yet).
>
> Well at that moment I am not sure what's the problem and having in mind
> what a mess my iterated kernels are, I am more inclined to blame my code. I
> hope you are right about execution time though - it would be easy to fix.
> Well except for stuff like rar or sha512crypt where reducing ndrange would
> lead to appaling occupancy and the kernel itself would need to be split in
> several parts, keeping intermediate data in global memory.
>
>
> On Tue, Jun 26, 2012 at 5:44 PM, Bitweasil <bitweasil@...il.com> wrote:
>
>> ...was everyone on this list except me? Hi, gw.
>>
>> From what I've seen, I don't think writing out of bounds is responsible.
>> If I simply change my runtime on my rainbow table generate kernels, I can
>> trigger the bug or go for days without it happening. The only difference is
>> how many steps it runs at a time. It's a very simple kernel, and the hangs
>> were happening at the 10-15% done mark - long before it is anywhere near
>> the bounds of an array. I've definitely gone romping through memory in the
>> past, and I know it causes weird behavior, but my table gen kernels are the
>> simplest and oldest kernels I have, and the steps per invocation value
>> changes nothing about their memory access.
>>
>> I'd love to be proved wrong, though! If it were kernel bugs, that's a
>> whole lot easier to deal with!
>>
>>
>> On Jun 26, 2012, at 0:02, Milen Rangelov <gat3way@...il.com> wrote:
>>
>>
>> On Tue, Jun 26, 2012 at 2:54 AM, magnum <john.magnum@...hmail.com> wrote:
>>
>>> Yes only now, and I was thinking more like 16K rounds x16. Not sure I
>>> want to go there unless AMD says somewhere that this is actually a design
>>> limit. Maybe they do? I would like to know the exact specified limit.
>>>
>>
>>
>> In fact I've tried this and it did not help. At present I am changing my
>> whole architecture and refactoring plugins, working currently on "fast"
>> ones. So I don't have much time to play with heavyweight kernels like rar
>> or wpa. Anyway I am becoming more and more confident that the ASIC hangs
>> are actually a result of kernel bugs - e.g out of bounds writes or
>> something like that.
>>
>>
>
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.