Hello,
could someone explain me the difference between http://www.jocl.org/ and http://jogamp.org/jocl/www/ ?
Advantages/Disadvantages ?
thx in advance
Hello
The projects are completely unrelated at the moment.
Some general words about both libraries:
jocl.org-JOCL: This is a library that aims at providing Java-Bindings for OpenCL that are very similar to the original C-OpenCL API concerning the function signatures and semantics. This JOCL is solely a Low-Level-Binding. The OpenCL API may be very verbose at some points, and this is not hidden or simplified, but simply offered by JOCL as-it-is, with the minimal adjustments that are necessary due to the language-specific limitations of Java. (The most significant difference in this case is that Java has no Pointers - therefore, JOCL has a ‚Pointer‘ class which resembles to a C pointer).
Jogamp-JOCL: In this library, the Low-Level-Bindings are generated automatically using the ‚GlueGen‘ library. These Low-Level-Bindings are also similar to the original C-OpenCL API, but not really intended to be used by clients. They mainly serve as the basis for the more important part of Jogamp-JOCL, namely the Object-Oriented abstraction of OpenCL. All the functions of OpenCL are offered in an Object-Oriented way, which simplifies the usage and may be found more natural (and of course, more convenient) for Java Programmers.
I’m probably not the right person to judge the advantages and disadvantages objectively 
But maybe one way of getting a first impression is to compare some basic examples. One of the most simple examples is a vector addition.
A vector addition in C-OpenCL is, for example, shown in the middle of this page.
The same vector addition is done in this jocl.org-JOCL sample Java file
And there is a vector addition using the Object-Oriented Jogamp-JOCL.
In fact, the confusion about both JOCLs seems to be increasing, and I’m currently discussing with the creator of the Jogamp-JOCL about this. I’ll add some general hints (like the ones summarized above) to the jocl.org main page. If this does not help to reduce the confusion, I’ll also have to consider renaming my project…
bye
Marco
Hello Marco13,
thank you very much for your reply, which helped me alot.
In fact, the confusion about both JOCLs seems to be increasing, and I’m currently discussing with the creator of the Jogamp-JOCL about this. I’ll add some general hints (like the ones summarized above) to the jocl.org main page. If this does not help to reduce the confusion, I’ll also have to consider renaming my project…
I doubt that renaming the project will help to understand the difference. Both projects are meant to wrap OpenCL to Java, so the names fit to the project’s intention.
I just wondered about the difference of both projects and especially why an installation of Jogamp-JOCL is done imo in a pedestrian way, whereas your project only needs the jar file from your page.
If you put an explanation like you did here on your homepage, it will help people who have the same questions and it should be sufficient, so imo you dont have to rename your project.
greetings,
Unregistriert
[QUOTE=Unregistriert]I doubt that renaming the project will help to understand the difference. Both projects are meant to wrap OpenCL to Java, so the names fit to the project’s intention.
[/QUOTE]
Agreed, though I’d ideally love to see a merger between the two projects: keeping the low-level API’s of jocl.org while adding the optional object-oriented layer on top of Jogamp. It’s not that competition is bad, but that the community would be able to use a single type-compatible Java library while choosing the approach that works best for them.
Is this being considered? I’m on the JOCL.org implementation right now because I like the low-level control, but am finding myself manually implementing a lot of the OO features that Jogamp already has. :-/ I think this would be the best move for the community and hope that it is given serious consideration.
Either way, thanks to all the implementors!
Yes, it is definitely considered.
I agree that using the low-level API may be tedious. Originally, I wanted to provide a nice OOP wrapper for my low-level JOCL as well, but Michael and Olivier (with JOCL and JavaCL) had been faster, so I decided not start a third one. But admittedly, when I’m writing my internal tests and samples, I usually use a “template”, because all the setup which is necessary for enqueueing a simple test kernel is all boilderplate code, and could easily be hidden.
I had been talking with Michael about a possible merge, namely the one that you suggested: JOCL.org as the low-level part, and Jogamp-JOCL as a convenient wrapper (although Jogamp-JOCL also has a low-level API, namely the ‘CL’ interface). A while ago, I downloaded the Jogamp-JOCL source, and tried to see what can be achieved there, but did not yet go very far with this - there are some notable differences internally. But maybe I/we will have another attempt for that.
bye
Marco
[QUOTE=Marco13]Yes, it is definitely considered.
I had been talking with Michael about a possible merge, namely the one that you suggested: JOCL.org as the low-level part, and Jogamp-JOCL as a convenient wrapper (although Jogamp-JOCL also has a low-level API, namely the ‘CL’ interface). A while ago, I downloaded the Jogamp-JOCL source, and tried to see what can be achieved there, but did not yet go very far with this - there are some notable differences internally. But maybe I/we will have another attempt for that.
[/QUOTE]
I think some sort of type-compatible merger would be best. I’m not as familiar with Jogamp, but it seems like it might be possible to rip out all the low-level Jogamp stuff, replace with JOCL.org implementations, and then ship everything under one name. This would:
[ol]
[li]Allow JOCL.org developers to stop re-writing the same code.
[/li][li]In theory be somewhat transparent to Jogamp users, assuming they’re usinig the higher-level APIs.
[/li][li]Allow for general type compatibility, allowing users of both/either (such as myself) to pick the library level that’s best for the current project.
[/li][/ol]
Of course, this was the intention. But again, there are differences “under the hood”, in the low-level-part, which make this quite difficult. The Jogamp-JOCL was not intended to be a wrapper for a completely abstract low-level binding, and JOCL.org was not intended to serve as a completely abstract layer for high-level-bindings.
Just as a simple example: The high-level classes (like “CLCommandQueue”) have some protected members:
- the CL interface
- the CLcontext
- the ‘long ID’
First of all, the CL interface instance would have to be replaced by the JOCL ‘CL’ class. The ‘long id’ is not present in JOCL, it is hidden by the low-level classes of JOCL.org. Some other classes have even more protected- and package private members. To summarize: It would literally be necessary to change everything in Jogamp-JOCL.
The “compatibility” issue that you have mentioned (Point 2) is a very strong concern - and assuming that some client has inherited from one of these classes and may be using some of these fields in client code makes it impossible to simply remove them or replace them with their JOCL.org-equivalents…
Theoretically, it should be possible to simply use JOCL.org as one implementation of the CL interface. And admittedly, if I had to rewrite JOCL from scratch, I’d implement the main CL class as an interface - it’s just much more flexible (as always when using interfaces). I considered to introduce an interface which is simply accessed through the static CL-Methods, but can be changed by calling something like CL.setImplementation(someImplementationOfTheCLI)…). This could be an advantage for a possible merge of the projects, but only a small one: The Jogamp-CL-interface and the JOCL.org-CL-class are also quite different. The CL-interface uses the ubiquitous “com.jogamp.common.nio.PointerBuffer”, and it would be necessary to write some sort of translation between instances of this class, and the low-level-classes of JOCL.org (like the Pointer class and all the classes like cl_mem etc.). The fact that JOCL.org can use Pointers to Java arrays, whereas in Jogamp-JOCL all Buffers have to be ‘direct’, may be another issue…
I’m not sure what you mean by “type compatibility” - but according to the points mentioned above: There would certainly be no direct compatibility between a CLCommandQueue and a cl_command_queue. In the simplest case, the CLCommandQueue would contain a cl_command_queue. And it actually does: The “long ID” is just the same thing as the long value which is hidden in the cl_command_queue. However, since the protected ‘long ID’ is part of the API of Jogamp-JOCL, it cannot be replaced by a cl_command_queue.
I’ll try to think about possible solutions for all this, once I have more time (maybe around the end of the year), but it will certainly not be trivial. And IF we merge the projects, there will probably be a tradeoff:
- Making the API and implementation of the merged project “nice” will break backward compatibility (of both projects, but probably the high-level-bindings would be affected stronger by this)
- Strictly keeping backward compatibility would cause some … odd implementation details. Again, a simple example: The CLCommandQueue would/could contain a ‘long ID’ and a cl_command_queue, which also contains the same ‘long ID’ value internally…
Thanks for the thoughts and notes. Please keep us posted on the direction on the project(s), and what (if any) help is needed. Thanks,
Preston