Enhancement: Decouple Aparapi from the current JNI layer, and allow it to work with other existing Java OpenCL wrappers.

[GoogleCodeExporter]

This is an enhancement request:

Currently Aparapi is composed of two main parts:

1) A set of methods that allows Java classes to be analyzed and recast into a 
form which can in turn be passed down to OpenCL for execution.

2) A set of C++ JNI classes that provide a wrapper of the underlying OpenCL 
code allowing the generated code from #1 to be executed.

Currently these two things are structured as two parts of a whole that can't 
really be separated from each other.  Together they form the 'whole' of Aparapi.

If the code were restructured to clarify and strengthen the dividing line 
between these two fundamentally distinct services then they could profitably be 
'decoupled' into two independent things.

The main value of Aparapi is contained in the functionality of #1 above.  There 
is obviously a need for *something* to fulfill the role of #2, but the way the 
two have been intertwined has made #2 become something of a drag on realizing 
the full potential of Aparapi.

Consider, if Aparapi were reengineered to be a pure 100% java library that 
would talk to a generic lower-level OpenCL Java library, then there could be 
many benefits.

At that point, a small set of thin adapter layers could be created to allow 
Aparapi to work with any existing (or future) Java OpenCL wrapping library (of 
which there are several).

This will decouple Aparapi itself from the issues and problems inherent in 
maintaing and debugging a hefty JNI library, freeing up Aparpi developer 
bandwidth to focus on higher levels of abstraction.

It will also be seen as a great new feature for those existing Java OpenCL 
libraries to be able to offer Aparapi functionality to their user bases, which 
will in turn help gain more growth and exposure for Aparapi.

Some users of the other Java OpenCL libraries have evaluated Aparapi, but been 
unable to switch because Aparapi currently hides much of the underlying OpenCL 
functionality, some of which is critical to advanced applications.  However, if 
those users could use Aparapi as a *layer* on top of the library they are 
already using then there would be no barrier to them getting on board!

In conclusion, the essential and unique value of Aparapi is located in the core 
ability to convert Java code into runnable OpenCL code.  Why not make that 
value more accessible to a broader audience by letting it work with existing 
Java OpenCL libraries?

Original issue reported on code.google.com by lats...@gmail.com on 31 Mar 2013 at 9:40

[GoogleCodeExporter]

A very interesting idea. We should try prototyping this, I don't think it would 
be *that* hard.  Essentially the OpenCL generation is all handled from Java 
side.  We do of course default to using our JNI code to 'hide' the minutia of 
buffer binding and arg handling.  

Are you thinking of JOCL (Marco Hutter's) or JOCL (from Jogamp)?  I do think 
this would be fairly straightforward. 

The Java classes ClassModel, MethodModel and KernelWriter would be pretty much 
all you would need.  We could even arrange for an Aparapi helper. 

Say 

java.lang.reflect.Method m = MyClass.class.getDeclaredMethod("run");
OpenCL openCL = Aparapi.createOpenCL(m);

OpenCL object/class would allow you to reflectively determine arg types, or you 
can just extract the text and do whatever you need to do using JOCL. 

String openCLtext = openCL.getText();

// use JOCL's BuildProgram, Buffer mechanism and dispatch to execute the 
OpenCL. 

Is this the kind of thing that you wanted?

Can you suggest a suitable API?  I really think this would be relatively 
straightforward for methods of classes. 

I am working on Java8 lambdas at present, this would be a lot harder for 
lambdas as they are specialized at the call site by javac, so we need the 
specialized form to convert to OpenCL. 

Great idea though.  Let's do it. 

Gary 

Original comment by frost.g...@gmail.com on 31 Mar 2013 at 3:35

[GoogleCodeExporter]

Gary,

I have to say I'm impressed by your receptivity to such a suggestion.  Thanks 
for being so open minded!  :)

I think Aparapi provides the missing piece that is going to help usher in the 
coming age of ubiquitous supercomputing, and so I want to see it's use expand 
as quickly as possible.

This page has a list of 4 different Java OpenCL libraries that are out there:

http://www.jocl.org/

I've been evaluating them, and right now I'm trying out Marco Hutter's JOCL.  
It's nice because it hews very closely to the unvarnished OpenCL C interface.  
This lets me get as close to the metal as I want, which is what I need for my 
current project.

You're correct that it wouldn't be *that* hard to get this idea up and running. 
 In fact, I'm already doing a hybrid version of it.  I created a class that 
uses Aparapi infrastructure to generate C code from my Java kernel (attached), 
that I then pass in to the JOCL API.

This lets me get immediate access to all the advanced features I need (async 
execution, direct queue management, events, etc.)

I think the JOCL guys would be very excited by this idea!

Original comment by n...@u1.com on 31 Mar 2013 at 6:44

Attachments:

• OpenCLSourceCodeExtractor.java

[GoogleCodeExporter]

This exact feature has actually been talked about for, I guess years now and 
there has always been push-back...I'm shocked to hear Gary say he wants to do 
this now. If I remember correctly, the previous argument against doing this was 
to prevent third-party dependencies within Aparapi.

FYI, this was one of the main drivers for a number of us to refactor the 
current Trunk code into a more OOP-style design, so that we could eventually 
identify and remove the underlying JNI code and replace it with an appropriate 
abstraction layer.

If you look at the existing Aparapi feature/bug list, you will see that we are 
also desperately looking for Aparapi to support Async execution and Events 
(OpenCL callbacks).

Having said that, I do not believe that adding some of these advanced features 
would be straightforward, considering how Kernel/KernelRunner are so tightly 
coupled. In my opinion, one path forward would be to completely decouple Kernel 
and KernelRunner, create a centralized Kernel dispatch service that accepted 
multiple Kernels and executed them as appropriate (sync/async/multi-GPU/etc). 
This would require an extensive refactoring though.

And if all of this was done correctly, we should be able to abstract the layers 
back far enough to support OpenCL and CUDA.

Original comment by ryan.lam...@gmail.com on 1 Apr 2013 at 6:56

[GoogleCodeExporter]

Two more things:

1) Removing the Aparapi JNI layer should make deploying Aparapi much easier, as 
Aparapi could be built using Maven and deployed as a Maven artifact to popular 
Maven repositories

2) We have been investigating JavaCL and have been impressed by a number of its 
features and recent developments (jna replaced by bridj, nativelibs4java 
support, Scala support, OpenCL-->Java code generation, Maven support, 
significant Mathematics libraries support (Goodies), etc.)

Original comment by ryan.lam...@gmail.com on 1 Apr 2013 at 7:19

[GoogleCodeExporter]

Ryan
Which JavaCL are you referring to? Is it https://code.google.com/p/javacl/?

Interesting.

Gary

Original comment by frost.g...@gmail.com on 1 Apr 2013 at 3:04

[GoogleCodeExporter]

Yes, that is the one.

Both the FAQ and Getting Started sections are very informative, but definitely 
not comprehensive. For example, in the Getting Started section, there is some 
example code at the bottom that shows how to both wrap existing .cl code (which 
Aparapi also supports, of course) and how to perform chained, asynchronous 
event execution.

Original comment by ryan.lam...@gmail.com on 1 Apr 2013 at 6:31

[GoogleCodeExporter]

I would like to point out that Lightweight Java Game Library (LWJGL) also 
contains an OpenCL binding.

Original comment by oakw...@minousoft.com on 11 Apr 2013 at 1:54

[GoogleCodeExporter]

Just a follow-up on this:

After trying out every OpenCL wrapper library I finally settled on using JavaCL 
(https://code.google.com/p/javacl/? ) which seems to me to be the best.

I'm using a modified version of the Aparapi library to simply convert my Java 
code into OpenCL compatible C code.

I then do everything else through JavaCL and just pass in the C code generated 
by Aparapi.

I do not use any of the Aparapi  infrastructure for automatically copying 
buffers as I prefer to manage that myself.

I found it to be much easier to manage multi-GPU code this way rather than 
trying to do everything via Aparapi (I'm running 4 x AMD 7990 cards, which show 
up in OpenCL as 8 separate GPU devices).

One enhancement that I would like to see is an improved ability to access all 
of the open CL defined functions, such as mad(), popcount(), 
async_work_group_strided_copy(), prefetch(), etc...

Even a simple ability to embed a string in my java code that would be passed 
through to the generated C code would be welcome.

In any case, being able to work in Java is a lifesaver.  It would be *much* 
harder to do all this great stuff without Aparapi!

Original comment by lats...@gmail.com on 21 May 2013 at 10:24

[GoogleCodeExporter]

Awesome stuff. 

I would be interested in seeing the code for this.

Do you have SVN/Github repo I could look at? Just so I can have a poke around..

In the lambda branch I have working code for the new Java 8 lambda expressions 
and would be interested in working out how to provide access to this. 

Also if there ever is a sustainable dalvik/android aparapi project, I think 
your separation of concerns would help there as well. 

Was there a lot of hacking required?

Original comment by frost.g...@gmail.com on 21 May 2013 at 10:52

[GoogleCodeExporter]

Gary,

Please email me at latsama@gmail.com, or call me (I sent an email w/my # to 
what I think is your address).

I don't have the code in a repo, but I would like to get it to you.

Original comment by lats...@gmail.com on 21 May 2013 at 11:16