Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 02 Sep 2015 20:06:18 +0200
From: magnum <>
Subject: OpenCL static/inline (was: Re: PHC: Argon2 on GPU)

On 2015-09-02 14:02, Solar Designer wrote:
> Regarding my testing with md5crypt-opencl:
> On Sat, Aug 29, 2015 at 09:48:48AM +0300, Solar Designer wrote:
>> Per this recent discussion, not inlining of functions isn't supported in
>> AMD OpenCL currently:
>> So I am puzzled why I appeared to have any performance difference from
>> including or omitting the "inline" keyword on md5_digest().  I'll need
>> to re-test this, preferably reviewing the generated code.
> I just did.  The generated GCN ISA code is exactly the same regardless
> of whether I use the "inline" keyword on md5_digest() or not.  The
> function is inlined for its every use either way.  And the code size is
> around 16000 bytes (some instructions are 4-byte, some are 8-byte).

Most/all drivers I know of will always inline, no matter what keyword 
you write (or don't write). Many drivers will quitely do this regardless 
of static and/or inline keywords. But more importantly, some drivers 
will not accept 'static' (neither with nor without 'inline') and others 
will demand either 'static' or 'inline' (but the result is still inline).

So the bottom line afaik is we should declare all and any functions in 
kernels as 'inline' (and not 'static'), for portability. Your recent 
patch to cryptmd5 kernel used 'static inline' and I had to change them 
to just 'inline' in order to get them working on [iirc] some semi-old 
Intel driver.

On another note, those BITALIGN definitions of yours now live in 
opencl_misc.h in case we'll eventually need them somewhere else.


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.