[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