First of all, sorry for the long delay in replying, and thanks for your
message. Also, please note that I have cc'd the pyopencl mailing list--I
hope that's ok with you.
On Wed, 26 Jan 2011 11:29:37 +0100, Olivier Chafik <olivier.chafik(a)gmail.com>
I'm Olivier Chafik, the author of JavaCL / ScalaCL / OpenCL4Java
Now that we have bindings for many languages and technologies, I feel like
some amount of convergence wouldn't hurt. Convergence of APIs on the Java
side has briefly been evoked in the past but it's precisely where everyone
tries to distinguish himself from his neighbour, and convergence of API
between languages just does not make sense, so I was more thinking about the
OpenCL kernels side.
Long story short, the latest JavaCL snapshots support #include include
directives in the hosted code that refer to files in the Java classpath, and
even support the syntax ((CLProgram)someProgram).addInclude("
;) to resolve remote includes.
This is done through basic #include parsing in the sources, eager includes
resolution + caching + adding -I compiler arguments.
You can see a demo of these includes in my latest Image Transform Kernels
The result is that this mechanism allows for cleaner composition and
reusability of OpenCL code. From a Java deployment perspective, adding an
OpenCL dependency amounts to add a Java dependency that only contains OpenCL
files in its resources. All this still being standard (pure OpenCL, with
relative file includes) and language-agnostic.
I've started grouping some OpenCL code in "LibCL", a JavaCL sub-project
thats 'includable' by any JavaCL program :
I'd be thrilled if you accepted to join forces to help build a standard
OpenCL on that model (hehe, and I didn't say there was anything good to keep
from this first attempt, it's just an embryonic bunch of quick refactors +
dirty naive ports from BSD code).
Now of course I thought, why stop at this productivity gain ? We could add
template engines that would make it possible to create meta programs and
work around the C / C preprocessor limitations (I saw you had similar
discussions on your mailing list recently and you used Mako).
This is where it becomes dangerous, because choosing a template engine makes
people write code that's not OpenCL anymore, and won't work accross multiple
bindings libraries (including the raw C bindings). I believe OpenCL is not
big enough yet, we still have a chance to avoid such fragmentation on the
kernel source front... Now that said, I dont know what templating engines
are available on Python, Java and others, so this might just not be possible
at all... (if *only* Apple could have chosen C++ over C !)
Anyway, sorry for this lengthy email... Please let me know what you think
about this if you have a minute or two :-)
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.
that limits us to StringTemplate  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.
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.
All of pyopencl's code will show up in this directory:
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. :)
Thanks again for being in touch,