Bug 1075

(In reply to comment #0)
> First needs a bit of research to figure out how to support
> co-existing multiple versions of OpenCL in a way similar to how JOGL does it
> for OpenGL (with GLProfile). 

I like this strategy very much, ofc!

> May be complicated by the fact that OpenCL
> already uses the word "profile" to describe "full vs. embedded", and uses
> "platform version" to describe "1.1 vs 1.2 vs 2.0".

IMHO we can keep 'embedded' for a later day,
since e.g. OpenCL 1.1 (at least) is already supported on some mobile
devices .. like some ARM chips (working on latest chipsets w/ Android).

CL, CL11, CL12, CL20 interfaces mapping their respective profiles 
and being implemented by one common CLImpl class might be possible
and useful.

I will ofc assist / help as usual.

Making progress on this. I've got JOCL working with the official OpenCL 1.1 headers now (previously the headers were a hacked pre-release version). Now I'm starting on adding the ability to have multiple versions of the headers co-existing.

Got the OpenCL 1.2 and 2.0 headers passing through GlueGen, and compiling the resulting Java/C code successfully. Had to comment out an anonymous union in OpenCL 2.0's cl.h file, since GlueGen doesn't yet support this sort of thing:

typedef struct _cl_image_desc {
    cl_mem_object_type      image_type;
    size_t                  image_width;
    size_t                  image_height;
    size_t                  image_depth;
    size_t                  image_array_size;
    size_t                  image_row_pitch;
    size_t                  image_slice_pitch;
    cl_uint                 num_mip_levels;
    cl_uint                 num_samples;
    union {
      cl_mem                  buffer;
      cl_mem                  mem_object;
    };
} cl_image_desc;

Next step is to figure out at runtime which version of OpenCL is present and load the correct implementation class.

I've now got a version working that supports three different OpenCL implementations: CLImpl11, CLImpl12, and CLImpl20. At runtime, you can request the latest implementation your device supports, and it will return one of these types to you as a CL reference. Then you can cast it to the correct implementation type and call new OpenCL 1.2/2.0 methods on it.

The high-level JOCL interface (CLBuffer, CLSampler, etc.) still uses a CLImpl11 object internally. This is because I didn't want to create three separate versions of all the high-level classes. You can still use the high-level interface with CL 1.2/2.0, but you'll have to use the low-level interface to call specific functions that didn't exist in CL 1.1.

I haven't yet thought of an elegant way for the JOCL high-level interface to fully utilize CL 1.2/2.0/futureCL without exploding the number of classes and interfaces in JOCL. There are 13 separate interfaces for CLBuffer/CLSampler/etc, so to create 3 separate versions of each is pretty ugly (and will be worse when CL 2.1 and any future versions come out). I'm open to suggestions in this area :)

(In reply to Wade Walker from comment #3)
> Got the OpenCL 1.2 and 2.0 headers passing through GlueGen, and compiling
> the resulting Java/C code successfully. Had to comment out an anonymous
> union in OpenCL 2.0's cl.h file, since GlueGen doesn't yet support this sort
> of thing:
> 
> typedef struct _cl_image_desc {
..
>     union {
>       cl_mem                  buffer;
>       cl_mem                  mem_object;
>     };
> } cl_image_desc;

We have to add support here ofc.

In the meantime, we could simply edit the structure
and decide for one of the values w/ the biggest size!
This allows dropping the union while preserving
accuracy.

> 
> Next step is to figure out at runtime which version of OpenCL is present and
> load the correct implementation class.

Excellent news!

(In reply to Wade Walker from comment #4)
> I've now got a version working that supports three different OpenCL
> implementations: CLImpl11, CLImpl12, and CLImpl20. At runtime, you can
> request the latest implementation your device supports, and it will return
> one of these types to you as a CL reference. Then you can cast it to the
> correct implementation type and call new OpenCL 1.2/2.0 methods on it.

Excellent!

Will we have common interface like JOGL's GL2ES2,
allowing to represent the common subset to the user?
This in turn will allow writing CL profile agnostic code,
at least partially.

> 
> The high-level JOCL interface (CLBuffer, CLSampler, etc.) still uses a
> CLImpl11 object internally. This is because I didn't want to create three
> separate versions of all the high-level classes. You can still use the
> high-level interface with CL 1.2/2.0, but you'll have to use the low-level
> interface to call specific functions that didn't exist in CL 1.1.
> 
> I haven't yet thought of an elegant way for the JOCL high-level interface to
> fully utilize CL 1.2/2.0/futureCL without exploding the number of classes
> and interfaces in JOCL. There are 13 separate interfaces for
> CLBuffer/CLSampler/etc, so to create 3 separate versions of each is pretty
> ugly (and will be worse when CL 2.1 and any future versions come out). I'm
> open to suggestions in this area :)

Lets think about this later on, after we have figured
out the common GL profile interfaces.
Maybe .. those can help resolving / simplifying the issue here.

[1] Will the implementing classes CLImpl11, CLImpl12, CLImpl20,
    being directly exposed to the user
    or via public interfaces, i.e. CL11, CL12, CL20?
    I prefer the latter, since it will be analog to [2].

[2] Common CL profiles as JOGL's GL2ES2
    being implemented by CLImpl11, CLImpl12, CLImpl20.
    For example:
     - CL11_20
     - CL20_21
    This will be analog to [1].

[3] How to solve/maintain the higher level API
    using the common CL profiles? -> [1] [2]

(In reply to Sven Gothel from comment #7)
> [1] Will the implementing classes CLImpl11, CLImpl12, CLImpl20,
>     being directly exposed to the user
>     or via public interfaces, i.e. CL11, CL12, CL20?
>     I prefer the latter, since it will be analog to [2].

Let me think about this for a little. The problem is, JOCL is written as a class-based wrapper around OpenCL, so we have this kind of structure, from the parent to child:

- CL*Binding: 11 interfaces, each with a .cfg file; each contains a subset of the CL functions that is selected manually in the .cfg
- CL: interface that inherits all 11 CL*Binding interfaces
- CLGL: interface that adds in GL-related functions
- CLImpl11/CLImpl12/CLImp20: class to implement all functions. These are what the user uses for the low-level interface.

Then there are also:

- CL*: classes to match the CL*Binding; each of them contains a CL*Binding object. These are what the end user actually uses for the high-level interface.

So the problem with versioning the interfaces/classes is, which ones do you version? There are three main choices:

- Version only CLImpl. This requires only one new class per OpenCL version, but doesn't let you use new OpenCL in the high-level interface, only in the low-level. This is what I have done up to now. Downside is the high-level interface stays at OpenCL 1.1 level.

- Version CL*Binding/CL/CLGL/CLImpl: This requires 14 new interfaces/classes per OpenCL version, and 14 new *.cfg files. It also requires the insides of the CL* classes to be flexible in what version of the bindings they contain; the classes would have to have OpenCL-version-dependent code inside them. I thought about doing this, but it would have required 42 new interfaces/classes + 42 new config files + touching all the CL* classes to get us to OpenCL 2.1.

- Version everything: This requires ~30 new interfaces/classes per OpenCL version, and gives you an explicitly versioned high-level interface. This is "filemageddon" -- we'd have like 100 new files :)

This is why I'm trying to think of a simpler way :) Ideally, there'd be a way where we create only a few new files per OpenCL version, and where we don't have a lot of hand-written, version-dependent code.

I thought of an idea to try: if I remove the 11 CL*Binding interfaces, this will greatly cut down on the number of interfaces we have to version. On the bad side, it means that high-level objects like CLKernel will internally use a CL interface directly, instead of using a CLKernelBinding interface that limits what functions of CL can be used. But on the good side, the number of gluegen invocations will be far less, and the inheritance structure of the generated interfaces/classes will be much simpler.

I'll try this speculatively and see if it blows up in my face :) If so, I can always revert it. If it works, then I can try creating:

- interfaces: CL11, CL12, CL20
- implementations: CLImpl11, CLImpl12, CLImpl20

(In reply to Wade Walker from comment #9)
> I thought of an idea to try: if I remove the 11 CL*Binding interfaces, this
> will greatly cut down on the number of interfaces we have to version. On the
> bad side, it means that high-level objects like CLKernel will internally use
> a CL interface directly, instead of using a CLKernelBinding interface that
> limits what functions of CL can be used. But on the good side, the number of
> gluegen invocations will be far less, and the inheritance structure of the
> generated interfaces/classes will be much simpler.
> 
> I'll try this speculatively and see if it blows up in my face :) If so, I
> can always revert it. If it works, then I can try creating:
> 
> - interfaces: CL11, CL12, CL20
> - implementations: CLImpl11, CLImpl12, CLImpl20

Yes, thats what I meant!

You then can even reduce it all to CLImpl20 .. impl.
all of them, if CLImpl20 contains all the other subs!
(Like JOGL's GL4bcImpl)

Note: This is for 2.4.0, i.e. API changes are fine.

So the higher level stuff can all use interfaces
and query the profile in use for optimizations.

OK, now I have the following hierarchy working:

CL --> CL11 --> CLImpl11
   \-> CL12 --> CLImpl12
   \-> CL20 --> CLImpl20

Where CL/CL11/CL12/CL20 are interfaces, and CLImpl* are classes. Gluegen is called only 4 times now, once to create CL.java, and once each for the three interface/implementation pairs. Future OpenCL versions should only require the addition of one *.cfg file.

Next step is cleanup, moving the interfaces to different packages, et cetera.

I've got a candidate version of these changes ready at https://github.com/WadeWalker/jocl/commits/bug_1075_add_new_opencl_versions. It compiles and passes all tests on Windows 10, Ubuntu 14.04, and OS X El Capitan. Please let me know if anyone has any final inputs before I check it in next weekend.

Code merged into master on my GitHub, JogAmp GitHub, and jogamp.org Git.