How to contribute a runtime function?

Asked by Erik Schnetter

I just downloaded pocl from launchpad, and it seems as if only a few run-time functions existed at this time. This is also mentioned in the TODO as high-priority item.

How would I go about contributing to the run-time library? Many such functions are type-generic, yet the examples I see (in lib/kernel: dot, mad24) seem to target specific types and vector sizes. Am I overlooking something? Or is this part not yet fully designed?

-erik

Question information

Language:
English Edit question
Status:
Answered
For:
pocl Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Carlos Sánchez de La Lama (csanchezdll) said :
#1

Hi erik,

I just committed a new revision (40) with an example of an overloaded kernel function, dot(). Look at lib/kernel/dot.cl to see how to do it. To implement a new function, just add the <function>.cl file into lib/kernel directory, update Makefile.am so it gets compiled, and include the prototype in include/_kernel.h

There are a lot of functions in the kernel runtime that are type generic (for example cos, is defined for float, float2, float4, ... types). We were thinking on a "template" mechanism to define those, but we finally thought that it is not worth the effort, and that defining the version for scalar types and making the vector version call it the appropriate number of times is enough. Of course, you are free to fit in any "template" for those generic type functions if you want.

Bear in mind we are considering externalizing the kernel library to libclc at some point, but in that case all the functions implemented here will be ported out so no effort will be lost.

Thank you for your will to contribute :)

Carlos

Revision history for this message
Erik Schnetter (schnetter) said :
#2

Carlos

I am very interested in the vector capabilities of OpenCL, and would therefore prefer a solution that is as efficient as possible. Calling a scalar function multiple times is probably sufficient for sin, cos, etc., but there are a few functions where many CPUs will offer vector instructions, e.g. sqrt, min, max, and these vector instructions should then be used.

Do you know how to do this with clang? Will clang do the right thing when a vector type is passed, since it understands vector types internally? Or do we have to provide the corresponding machine-specific instructions, or extend clang/llvm?

Also, I did not quite understand what you suggest I do regarding vector instructions. Should just the scalar functions be implemented at the moment, and the vector functions would be expanded automatically? Or should I (we) implement the corresponding vector versions as well, either directly or via a template mechanism?

I'll try to contribute my full dot() implementation, just to see how to commit with bzr.

-erik

Revision history for this message
Erik Schnetter (schnetter) said :
#3

Carlos

I committed some code to <bzr+ssh://bazaar.launchpad.net/~schnetter/pocl/main>. This implements cos, fabs, sin, sqrt, tan, as well as some conversion functions. I added the corresponding declarations to _kernel.h, and it is quickly becoming obvious that there will be very many of them.

I also took the liberty of using the low-level vectorised implementations of fabs and sqrt if the CPU supports SSE2 etc.

I am looking forward to your comments, in particular if you think the code should be reorganised in some way. If I continue in this project, I will likely implement a template mechanism of some kind. Since I don't think that #include is available in OpenCL, I am thinking e.g. of m4 as a preprocessor for the run-time functions.

-erik

Revision history for this message
Pekka Jääskeläinen (pekka-jaaskelainen) said :
#4

Further discussion has been moved to the project mailing list:
https://sourceforge.net/mailarchive/forum.php?forum_name=pocl-devel

Can you help with this problem?

Provide an answer of your own, or ask Erik Schnetter for more information if necessary.

To post a message you must log in.