I’m using OpenCL for accelerating tasks, but all of them have also a C++ alternative implementation (so my applications can be configured to either choose the OpenCL implementation or the C++ alternative implementation).
However, if I link my application with OpenCL, the OpenCL runtime will be required to start the application, or otherwise the executable will fail to start AFAIK.
Has anybody developed any “intelligent” library, as a layer between OpenCL and the application, so that for example you get a pointer to each OpenCL API function, initialized to NULL if no OpenCL runtime is available, or to the actual function if the runtime is available? That way, my application will run no matter if the user has installed the runtime or not, while I can display some sort of advice dialog telling performance will be increased if a runtime is installed on supported hardware.
My applications run on Linux, Windows, and OSX, so I’d need this solution for all three OSs.
[QUOTE=Dithermaster;30569]On any recent Mac OS X (10.6+) the runtime will always exist.
On Windows you can use /DELAYLOAD and an alternate clGetPlatformIDs implementation that returns 0 for when the OS can’t find OpenCL.dll.[/QUOTE]
Thanks, but I believe the wrapper method is the most failsafe one, that will work in no matter what strange scenario you find. I’ll use a dynamic loader wrapper.
[QUOTE=kunze;30566]OpenCV implements something like this and has similar portability requirements. It may not do exactly what you want, but perhaps it’s a start. Check this out:
And to be clear: this is not my work, so I can’t take credit/blame for it. :)[/QUOTE]
Thanks a lot. Searching a bit, I found other similar wrappers, such as CLEW (a part of a larger project), and also some wrapper used for a electromagnetic particles simulator IIRC. However, all of them are limited to either 1.0, 1.1, or 1.2. Just for the sake of completeness, and for getting ready for the future, I’d like to implement 2.0 support in the wrapper. Can I easily do that by just adding the prototypes of new API functions an querying their pointers? Or is there any severe change from 1.2 to 2.0 that would complicate the wrapper?
You’ll see that clCreateCommandQueue, clCreateSampler, and clEnqueueTask are deprecated. I suspect most implementations you’ll use will have these implemented. But theoretically, if an implementation just has OpenCL 2.0, these might not be included. So you’ll have to handle this gracefully if you build a shim library on top of OpenCL.
You’ll see that clCreateCommandQueue, clCreateSampler, and clEnqueueTask are deprecated. I suspect most implementations you’ll use will have these implemented. But theoretically, if an implementation just has OpenCL 2.0, these might not be included. So you’ll have to handle this gracefully if you build a shim library on top of OpenCL.[/QUOTE]
Looking at http://www.khronos.org/registry/cl/sdk/2.0/docs/man/xhtml/deprecated.html , if I’m reading it correctly, there aren’t deprecated functions in 2.0, but however there’re deprecated ones in 1.2 and 1.1. Thanks for the comment, I didn’t know there were deprecated functions…