I’ve come across a nasty binary incompatibility between AMD’s and nVidia’s OpenCL SDKs for Windows, even though they are both OpenCL 1.0-comformant.
nVidia just used the cl_platform.h as-is, while AMD added _stdcall to the definition.
According to AMD, this was agreed with Khronos, however, the cl_platform.h on this site doesn’t contain stdcall anywhere, even though it does have some platform-specific things for Apple and Win32.
So the calling conventions aren’t compatible, that is one thing.
Another thing is the naming convention.
nVidia just exports the ‘clean’ symbol names in their DLL, eg “clReleaseMemObject”.
AMD however, exports the decorated stdcall name, eg “_clReleaseMemObject@4”.
This causes another incompatibility.
My guess is that nVidia got the exported symbols right, and AMD got the calling convention right, assuming OpenCL is supposed to work the same as OpenGL, which has undecorated names (better compatibility with various languages and tools), and uses stdcall (the default convention under Windows).
Could you do something about this? If nVidia mistakenly used cdecl (as AMD claims), then I suppose you should tell them to update their SDK, and perhaps you should also update the cl_platform.h on this site by adding stdcall to it.
As for the exported symbols. Perhaps it’s a good idea to also provide a standardized .def file for the OpenCL.dll on Windows, where all the symbol names and their ordinals are uniformly defined, so we can have binary compatibility between multiple vendors?
That way we don’t have to wait for an ICD model to be standardized and implemented. That could take months, while this symbol/naming convention problem could be fixed in no time. It just needs to be properly defined (and perhaps the current OpenCL 1.0-conformance labels need to be stripped from both SDKs and drivers, until they fixed them to be compatible).
Thanks in advance