[PyOpenCL] Fwd: Cooperation between PyOpenCL / JavaCL (/ others) ?

Olivier Chafik olivier.chafik at gmail.com
Sat Feb 5 09:27:29 PST 2011


Hi Andreas,

2011/1/30 <lists at informa.tiker.net>

First of all, sorry for the long delay in replying, and thanks for your
> message.


Ugh, sorry for the even longer reply... Was busy releasing the latest
versions of JavaCL and ScalaCL and with my real-life job at the same time...
Anyway, thanks for your reply !


> Also, please note that I have cc'd the pyopencl mailing list--I
> hope that's ok with you.
>

Sure, hi all :-)


> A collaboration like this certainly sounds like a good idea.
>
> If we insist that such a collaboration centers around shared code, that
> would depend on a common templating technology.
>

Hehe, I'm open to any kind of collaboration, it's just the first one that
came to my mind... Let other proposals flow ;-)


> According to
>
> https://secure.wikimedia.org/wikipedia/en/wiki/Template_engine_(web)
>
> that limits us to StringTemplate [1] and Mustache [2,3]. If you know any
> other candiates, please point them out. Unfortunately, Mustache makes
> many things that are simple in Mako (such as unrolling a loop based on a
> count) rather difficult because of the absence of actual logic,
> StringTemplate less so.
>
> [1] http://www.stringtemplate.org/
> [2] http://mustache.github.com/
> [3] http://mustache.github.com/mustache.5.html
>
>
Seems like StringTemplate could be a winner, then.
So far I've only used Velocity, I'll try experimenting with StringTemplate
to see if there are annoying limitations or not.


> In any case, since potentially significant bits of (non-shared) host
> code need to be written for each (shared) kernel, I think that explicit
> kernel code sharing might be a bit too heavy-handed, and that we can
> probably get by with occasional mutual 'manual' stealing.
>

I'm okay for mutual manual stealing, but I don't think it would be that hard
to share the exact same OpenCL code between different bindings.

For instance I've just ported some Apple code that does parallel prefix sum
:
http://developer.apple.com/library/mac/#samplecode/OpenCL_Parallel_Prefix_Sum_Example/Introduction/Intro.html

I didn't touch to the OpenCL kernel at all (just added a `#define DATA_TYPE
float` to scan_kernel.cl) :
http://code.google.com/p/nativelibs4java/source/browse/branches/OpenCL-BridJ/libraries/OpenCL/ScalaCL2/src/main/resources/scalacl/impl/scan_kernel.cl

I wrote a literal translation of the scan.c C host code to Scala :
http://code.google.com/p/nativelibs4java/source/browse/branches/OpenCL-BridJ/libraries/OpenCL/ScalaCL2/src/main/scala/scalacl/impl/ApplePrefixSum.scala

Once I got this literal translation to work, I transformed the code into
some more idiomatic Scala version :
http://code.google.com/p/nativelibs4java/source/browse/branches/OpenCL-BridJ/libraries/OpenCL/ScalaCL2/src/main/scala/scalacl/impl/GroupedPrefixSum.scala

Even though the resulting host code looks rather different from the original
C version, the OpenCL kernel is strictly the same.
I could be wrong, but I believe the same could be hold true of all the
OpenCL kernel we could write, especially with a common template system :-)


> All of pyopencl's code will show up in this directory:
> http://git.tiker.net/pyopencl.git/tree/HEAD:/pyopencl
>
> If you can point us to a permanent place where your code is availble,
> then I'd say a mutually beneficial future of theft is assured. :)
>

Sure, JavaCL's source repository is here :
http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL

With the following locations for OpenCL code :

JavaCL's util package :
http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL/JavaCL/src/main/opencl/com/nativelibs4java/opencl/util/

LibCL :
http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL/LibCL/src/main/resources/LibCL/

JavaCL's demos :
http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL/Demos/src/main/opencl/com/nativelibs4java/opencl/demos/

JavaCL's OpenGL demos :
http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL/OpenGLDemos/src/main/opencl/com/nativelibs4java/opencl/demos


To make it easier to share our code, I've just setup a git repository :
https://github.com/ochafik/LibCL

I'm not good with git, but I believe you'll have no problem forking /
contributing from there and merge the changes to our respective repositories
if needed :-)
Ideally we could all put our (reusable) OpenCL code there, whether it fits
into the 'LibCL' principle (kind of a new libc) or it is more specific demo
code.
Then the other library wouldn't have to adapt immediately / use immediately
that code, but a direct link to the host code's implementation in the kernel
source code might make it easier.

Looking forward to reading from you guys !
Cheers
--
zOlive
http://ochafik.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tiker.net/pipermail/pyopencl/attachments/20110205/962f1090/attachment.html>


More information about the PyOpenCL mailing list