3rd-party SDKs : a chaos

Hi,

I’m tired. Really tired of seeing how the XXXXX’s-vendor SDK is not compatible with YYYYY’s-vendor implementation. For instance, if you compile a program with the ATI’s SDK it won’t run using a NVIDIA card. Also, the Intel’s SDK eats the NVIDIA’s DLLs and registry keys…

I think the solution is that Khronos should release not only the .h files but also the OpenCL.lib/.a to find the ICD DLL, load it and get the clXXXXXXX function pointers.
It’s very easy: for Windows, you should release a OpenCL.lib that finds the ICD in the registry, then call LoadLibary and get the function pointers with GetProcAddress().

I really think this is the only valid solution because IHVs seem to be very occupied fighting against them and, who looses, is the poor programmer who simply cannot write a truly multivendor-compatible OpenCL app with guarantees.

Thanks.

Btw, the .lib could be just inlined in the .h, something like:


void clInit ()
{
   #ifdef WINDOWS
      // Find OpenCL ICDs in the registry
      OpenRegKey(....);
      //Load the ICD DLLs
      LoadLibrary(...);
      //Get the function pointers
      clGetPlatformID = GetProcAddress(hDLL,"clGetPlatFormID");
      ....
   #else
      ...
   #endif
}

I think making it open source/inlined will be better than releasing the .lib.

finally, it would be a good idea to incllude several examples in the official Khronos SDK, so you can use it as a testcase to check the SDK’s compatibility of the different 3rd-party implementations.

I have a very similar framework to your example (dynamically loading the library and functions), and having used some of the available sdk’s, agree entirely with your point. A lot of the vendor-specific headers give minimal added functionality for OCL (Stream gives you a bitmap reader/writer, command-line parser, and some other tidbits) but not enough to justify the blow to compatibility. It seems to me that vendors are bloating the sdk for competitive reasons rather than technical ones…

Also, with ATI’s sdk, many samples will ONLY create an ATI platform, regardless of what you have installed, by querying the platform name/id. All the samples can be stripped down to a compatible working version without any of the <atistreamsdk> headers, however.

I want to release the framework I’m making soon, as it supports multiple platforms and dynamic loading of the OCL library. I like your suggestion to dynamically load the ICDs in the registry, will see if it’s possible to incorporate that as well.

tl;dr : Seconded!

We use an ancient AMD SDK for just that reason: it keeps us OpenCL 1.1/1.2 “clean” (no 2.x APIs because they are not in the header) and the .lib works with old and new OpenCL.dll instances. You only need the .h and the .lib/.a, and as you point out you could even skip that and dynamically load the DLL. Then the only function pointer you need to look up is clGetPlatformIDs since it gets you everything else.

You can use LoadLibrary/GetProcAdress/dlsym. It’s working fine on Windows/Android/Mac OS X.