[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 25 Jun 2012 18:06:31 -0700
From: Bit Weasil <bitweasil@...il.com>
To: Solar Designer <solar@...nwall.com>
Cc: john-dev@...ts.openwall.com
Subject: Re: OpenCL kernel max running time vs. "ASIC hang"
> I think we should have this configurable (at least compile-time) and
> should try different values.
>
Compile time is difficult, unless you're targeting only specific GPUs. A
slow GPU (say a GTX260) and a fast GPU (a 7970) will require very different
values. Typically, there is some per-kernel overhead that cannot be
avoided. If you tune for a slow GPU, you end up spending more time on
overhead than needed on a fast GPU. If you tune for a fast GPU, you end up
running long on slow GPUs, and either triggering the kernel killer, or bugs
in the driver.
>
> > 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.
>
> I guess this is not documented.
>
> Besides the "ASIC hang" risk, the kernel runtime may also need to be
> tunable for optimal performance vs. good interactivity, as Bit Weasil
> has pointed out.
>
AMD doesn't document anything interesting, nor do they bother responding to
bugs. atom of hashcat, gat3way of hashkill, and myself have all spent long
hours arguing with their OpenCL implementation vs the spec. For a long
while, they were somewhere between glitchy and flat out wrong, and they do
not seem to care. So work around it in any way you wish. :) I just assume
that bugs in their drivers may be fixed at some point, and then will
probably be unfixed in a later version. They're really bad with them.
My solution is short kernel runtimes. If you find anything better, let me
know!
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.
