Results 1 to 7 of 7

Thread: Running without OpenCL runtime if it's not installed

  1. #1
    Junior Member
    Join Date
    Aug 2014
    Posts
    13

    Running without OpenCL runtime if it's not installed

    Hi,

    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.

    Does this exist?

    Thanks!

  2. #2
    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:

    https://github.com/Itseez/opencv/blo...re/src/ocl.cpp

    And to be clear: this is not my work, so I can't take credit/blame for it.

  3. #3
    Senior Member
    Join Date
    Dec 2011
    Posts
    190
    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.

  4. #4
    Junior Member
    Join Date
    Aug 2014
    Posts
    13
    Quote Originally Posted by Dithermaster View Post
    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.
    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.

  5. #5
    Junior Member
    Join Date
    Aug 2014
    Posts
    13
    Quote Originally Posted by kunze View Post
    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:

    https://github.com/Itseez/opencv/blo...re/src/ocl.cpp

    And to be clear: this is not my work, so I can't take credit/blame for it.
    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?

    Thanks!

  6. #6
    The only trick will be dealing with deprecated APIs. You can see those by looking at the end of the OpenCL 2.0 header file:

    http://www.khronos.org/registry/cl/api/2.0/cl.h

    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.

  7. #7
    Junior Member
    Join Date
    Aug 2014
    Posts
    13
    Quote Originally Posted by kunze View Post
    The only trick will be dealing with deprecated APIs. You can see those by looking at the end of the OpenCL 2.0 header file:

    http://www.khronos.org/registry/cl/api/2.0/cl.h

    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.
    Looking at http://www.khronos.org/registry/cl/s...eprecated.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...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •