Support for image types

I don't see a way to create several of the image types that are supported by OpenCL in jocl.
i.e. image1d_t, image1d_buffer_t, image1d_array_t, image2d_array_t
c.f. https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xhtml/otherDataTypes.html

I also don't see a way to use the low-level binding API to call clCreateImage with the right parameters since it doesn't seem to be exposed on CLImageBinding
https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xhtml/clCreateImage.html

It is in the header file though. So, not sure why its not available?
https://github.com/JogAmp/jocl/blob/master/make/stub_includes/CL12/cl.h#L676

Is there a way to do this?

Have you looked at the com.jogamp.opencl.CLImage2d (and similar) types? If you can't do it with the object-oriented wrapper, you should be able to get access to clCreateImage2D() relatively directly this way. There's a test in test/com/jogamp/opencl/CLImageTest.java that shows how to use it.

Yes, I have seen the CLImage2d and 3d types. However, these don’t represent the types I’m looking for. Regarding the low level binding, I’m looking particularly for this function https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xhtml/clCreateImage.html since it allows the parameters to to create an image array or 1d image to be created. As far as I know this function was added in opencl 1.2. I linked the header where it’s defined in the post above , however, it doesn’t seem to be in the low level binding

Hmm, yeah you're right. The cl.h header file we build from contains clCreateImage(), but there's no entry point for it in CLContext.java, it only contains the 2D and 3D variants. I guess if you want the 1D image ability, you'd need to modify CLContext slightly to support it.

Right, but even when looking at the low-level binding, I don't see `clCreateImage`, unless I'm looking in the wrong place.

In CLImageBinding, the methods I see in my version (2.3.2) are

long clCreateImage2D(long var1, long var3, CLImageFormatImpl var5, long var6, long var8, long var10, Buffer var12, IntBuffer var13);
long clCreateImage2D(long var1, long var3, CLImageFormatImpl var5, long var6, long var8, long var10, Buffer var12, int[] var13, int var14);
long clCreateImage3D(long var1, long var3, CLImageFormatImpl var5, long var6, long var8, long var10, long var12, long var14, Buffer var16, IntBuffer var17);
long clCreateImage3D(long var1, long var3, CLImageFormatImpl var5, long var6, long var8, long var10, long var12, long var14, Buffer var16, int[] var17, int var18);
int clGetImageInfo(long var1, int var3, long var4, Buffer var6, PointerBuffer var7);

Am I looking at the wrong part of the low-level binding? Any reason that method would not be included?

To get to that function, you need to use the low-level bindings. If you look in jocl/test/com/jogamp/opencl/LowLevelBindingTest.java, there's an example of using the com.jogamp.opencl.llb.impl.CLImpl12 and com.jogamp.opencl.llb.impl.CLImpl20 objects (the low-level bindings to CL 1.2 and 2.0). Both of these objects have

public long clCreateImage(long context, long flags, CLImageFormatImpl image_format, CLImageDescImpl image_desc, Buffer host_ptr, IntBuffer errcode_ret)

 defined. I guess for whatever reason Michael just didn't include this function in the high-level interface.

Ok, I see. Thanks for looking into this!

I'm using the latest version that is available on maven central (2.3.2) and it doesn't have CLImpl12 and CLImpl20, so thats why I missed it.

https://search.maven.org/artifact/org.jogamp.jocl/jocl-main/2.3.2/jar

Is the recommendation to build the latest version from source, or will it be published to maven central at some point?

Also, I'd be happy to expose the additional image types in the high level API and submit a PR, once I figure out how to access the low-level binding :)

You shouldn't have to build from source, you can just download the latest JARs from jogamp.org instead of getting the older ones from Maven. Or alternately, I forgot who puts JogAmp stuff on Maven Central, but maybe if you look around a bit in the forums you can see who did it and ask them to put up a more recent version :)

PRs are always welcome, of course :) The high-level interface is difficult, since it's trying to convert a big bag of loose functions defined by Khronos into something that looks object-oriented. Then add to that the fact that every point revision from Khronos potentially means a new numbered version of all the CL objects, in order to keep them all separately usable, and you have to decide what version of OCL the high-level interface will represent... or do you somehow let the user pick? It almost might be easier to just use the low-level interface for everything, so that your code looks as similar to C OpenCL as possible :)

Thanks for the pointer to the downloads. I found them here https://jogamp.org/deployment/archive/rc/
Seems there are only RC versions after 2.3.2, no official releases. So, thats probably why no newer versions are on maven central.

In my own internal code, I'm probably going to write some abstraction / wrapper over the C binding anyway. So, just figured I could upstream that. Is there any official position about what version of OpenCL the high level API represents?

I was imagining just adding some new methods like CLContext#createImage2dArray, CLContext#createImage1d etc
and checking the OpenCL version, and if the function is not supported throwing an exception.

Hmm.. looks like its going to be painful to bring in the new version in my environment, since I'm using processing https://processing.org/ which relies on jogl 2.3.2 and using the new version of jocl created link errors

java.lang.NoSuchMethodError: com.jogamp.common.util.cache.TempJarCache.isInitialized(Z)Z

Yeah, it might be a little painful to shove a newer version of JOGL/JOCL into Processing. That's something I haven't tried up to this point. I know the TempJarCache is a relatively new feature where the native libraries can be expanded from JARs at runtime. I'm not sure how much trouble it would be to get Processing to work with the new version. At least for my own apps, it was relatively straightforward to change a few small things. But I've never tried to build Processing, though :)