clCreateImage{,2D,3D} vs the ICD loader

Hi there,

As part of PyOpenCL, I am trying to supply one interface to clCreateImage{,2D,3D}. It turns out to be harder than I thought to figure out which one to call.

My first idea was that as long as the header you compiled against (and thereby the ICD loader) offered the 1.2 function clCreateImage, then you would call that, and the translation to the older functions would be done for you behind the scenes. Unfortunately, none of the ICD loaders I’ve tried behaves this way.

In fact, for implementations that don’t supply the 1.2 function, calling clCreateImage leads to a crash.

The spec doesn’t say anything about this topic. It would be good if it did. It would be even better if it specified that the loader has to do some translation.

The current situation is highly unpleasant–it means I have to go and parse version numbers just to figure out what functions are safe to call for each and every platform.

I’d much appreciate any comment on this.


I have found the same issue with Nvidia. For my work, I’ll just stick to OpenCL 1.0 for the moment. I don’t see any evidence of code to handle this backwards compatibility in cl.hpp from either Khronos or the version 1.2 preview in AMD APP.

I think you will have to write code to check which version is supported and then provide a wrapper function that calls the appropriate clCreateImage variant. You will have to do that for all of the OpenCL 1.2 functions.

A suggestion to Khronos: please build in this sort of automatic translation into cl.hpp. A possible approach would be to have four versions of each class: a base class, e.g. cl::Platform, but then provide CL 1.0, 1.1 and 1.2 versions that inherit from cl::Platform. All the versions should try to provide the same functionality as the 1.2 version, hiding the implementation tricks from the user. If some function really cannot be provided, rather through an exception when someone tries to use that function instead of the program suffering a segfault.

Thanks vdanjean for pointing out that OpenCL 1.1 implementations don’t need to implement deprecated OpenCL 1.0 functions. I was going to try to get by with OpenCL 1.0, irrespective of the platform, but now I see that isn’t guaranteed to be portable either.

vdanjean, I’m curious what happens when OpenCL 1.3 or whatever the next version number will be is released. Code written against OpenCL 1.0 - 1.2 specs could get by with parsing the OpenCL version string when the ICDs only have versions from 1.0 to 1.2.

What happens when encountering an ICD with a later version number where, once again, some older functions have been deprecated and are no longer implemented? Is there some way for the application to ask “Do you support OpenCL 1.0/1.1/1.2?” Naturally, the app could just produce an error when encountering a version string it doesn’t recognise, but what about say AMD’s implementation which supports v1.2 but still provides v1.0 functions? The app would have no way of knowing that v1.0 functions are available.

How should one future-proof oneself in this situation? Or are we basically stuffed?

Thanks for the info vdanjean.