What are the differences between the various OpenCL SDKs

1
votes

I'd like to learn how to use the OpenCL API, however I am a bit confused about how to "install" OpenCL for development. The various articles on Google are conflicting and I suspect some are obsolete.

My understanding is that Khronos group provides the specification and then various companies provide an SDK that complies with that specification.

As I understand it you need:

  1. The OpenCL headers, which can be downloaded from the Khronos site
  2. The OpenCL library, which comes with the various SDKs

Is there a difference between the different SDKs? From what I can tell the options are Intel, AMD or Nvidia. I've read conflicting information about whether it matters what SDK you use - some sources say that the SDK is just for the developer and the binaries that are produced will work on any hardware that supports OpenCL while other sources say that using a particular SDK locks your application into one vendors hardware. Which is it? Does it matter which SDK I choose to use and is there a non-vendor specific OpenCL library that I can link to?

4
sdkopencl
Pieces that are different: tools (e.g. profiler), libraries, samples, documentation that explains how to write vendor-optimal code. Also watch for OpenCL version. E.g., NVIDIA is stuck with 1.1. Pieces that are the same: header files, ICD (library which you link against). Output executable files are identical. - void_ptr

4 Answers

5
votes

OpenCL SDKs are different. They provide tools to ease the developing, additional functions, samples, and documentation. Every manufacturer will include what it suits best their hardware, but they all should be compatible when the app is compiled.

The ".lib" ".a" OpenCL library that gets linked into the app (the one that comes in the SDK) is the same in all the cases (except if they have different versions, 1.1, 1.2, 2.0). This is because the library is not really a library, but only a stub to the real functions in the real driver. This also explains why the headers are all the same, they all link against the same library.

All the apps, no matter what SDK should be the same after compiling.

In the case of nVIDIA, additionally to their OpenCL.lib, they provide some functions to ease the platform acquisition (oclGetPlatformID() in oclUtils.h) and so on, that are not available on other drivers, and it is recomended NOT to use them unless you want to end up having to pack another nVIDIA propietary library to your app.

But if you really want to be generic, then you should go for dynamic library loading (dload(), LoadLibrary()). Which will make your app work even in situations where the system does not even have OpenCL installed.

4
votes

You are correct, all SDKs use (or should use) the Khronos headers. You could also just use the Khronos headers yourself.

On Windows, you'd link to OpenCL.lib, which is just a static wrapper around OpenCL.dll (installed by your graphics driver in \Windows\System32). Everyone's wrapper should be similar for the same version of OpenCL. It is also supplied by Khronos (the ICD is open source) but it is easier to use one from an SDK.

OpenCL.dll uses the ICD mechanism to load the runtime(s) installed by each driver. If you have multiple runtimes installed, they each show up as a cl_platform.

If you are targeting OpenCL 1.1 (due to NVIDIA) I suggest using the version 1.1 header to ensure you don't accidentally use newer API.

0
votes

While the OpenCL aims to abstract code from hardware, there are several different types of GPU architectures. These differences force writing specific code for specific hardware. Hence it is not easy to write a portable code. IMHO, you are better off selecting one hardware and utilize developer friendly SDK for that platform.

What is the use case you are trying to solve?

0
votes

The binaries can be compiled at runtime (at least in Java). Therefore a OpenCL-C-runtime (?) is needed, but the compiled kernel are mostly hardware-dependent.