[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 18 Jul 2015 12:09:37 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: Lyra2 on GPU
On 2015-07-18 11:27, Agnieszka Bielec wrote:
> 2015-07-17 21:09 GMT+02:00 magnum <john.magnum@...hmail.com>:
>> On 2015-07-17 20:41, magnum wrote:
>>>
>>> On 2015-07-17 20:03, Agnieszka Bielec wrote:
>>>>
>>>> 2015-07-17 18:29 GMT+02:00 magnum <john.magnum@...hmail.com>:
>>>>>
>>>>> I tried building your code but it's broken for OSX:
>>>>
>>>>
>>>> OS X doesn't have pthread_barrier_t but I had problems with speed on
>>>> lyra2-lm on super when I was using barriers in openmp, and only this
>>>> change made that the speed is normal, I will decide what I will do
>>>> with this error, if you want to test my code I recommend you to switch
>>>> to commit e6a532b40e4c98418913075b5407e50765f2298a because my newest
>>>> commit works on super on both cards but in my laptop doesn't work when
>>>> LWS=GWS (cmp_all(1) failed) and I don't know if this is bug in my code
>>>> or somewhere else. and to make my code compiling it's enough to remove
>>>> files whose name begin with "Lyra2"
>>>
>>>
>>> I'll try that.
>>>
>>> Perhaps you can use the pthread barrier stuff "#ifndef APPLE", with a
>>> fallback to OpenMP barriers. Or we could check for it in autoconf.
>>
>>
>> Several other problems. The yescrypt-opencl format use "ulong" which doesn't
>> exist (on host side) here. You need to use cl_ulong or uint64_t instead. And
>> I see lots of uses of "long" too. This should never be used in host code -
>> it may end up as 32-bit. You probably want to use int64_t or cl_long for
>> them.
>
> I don't see the problem, I'm using uint64_t in salt which is copied to
> memory on GPU
Even if ulong in host code somehow works on your system it's definitely
not portable. Even changing it to "unsigned long" isn't.
>> The kernel build produces a boatload of warnings that you need to fix:
>
> I don't have these warnings of Lyra2 but I will try to fix all using your output
> warnings of pomelo I'm getting on super AMD
All OpenCL functions has to be either static, inline or __kernel. Simple
as that. The warnings for comparing signed with unsigned are silly but
they need to be fixed anyway since we can't mute them - and in fact they
sometimes do reveal bugs that are hard to spot.
BTW I gave you the advice long ago to always use unsigned for everything
which doesn't actually need to be signed (in kernels). It's faster and
you'll avoid most problems like this (if you get this warning then, it's
more likely to actually reveal a real bug).
magnum
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.
