PDA

View Full Version : 3rd-party SDKs : a chaos



pelotoescogorciao
01-25-2011, 06:23 PM
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.

pelotoescogorciao
01-25-2011, 06:29 PM
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.

chai
01-26-2011, 11:46 AM
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!