Conflicting calling and naming conventions AMD/nVidia

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

Thanks for pointing this out. The next release of NVIDIA’s OpenCL SDK will use the __stdcall calling convention rather than _cdecl. This will require re-compiling old binaries to work with the new driver.

Note that this wasn’t really a mistake on our part, Khronos only recently came to a consensus.

Thanks Simon.
What about the exported symbol names (and possibly ordinals) though?
I was thinking, if Khronos would standardize the name of the DLL now (is it going to be OpenCL.dll or OpenCL32.dll, for the ICD model?) and supplies a proper definition for the exported names in a .def file or such…
That would make it easy for the nVidia and AMD SDK to be binary compatible for now, by just placing the proper DLL in your search path, and in the future, the ICD model could just be installed ‘in place’, because the actual calling convention of the ‘proxy’ OpenCL.dll that will load the ICDs would then still be binary compatible with the stand-alone drivers we have today.
This would guarantee that as soon as the SDKs are updated and recompiled, we will then have binary compatibility between vendors, and future compatibility with the ICD already built-in. There would be no need to recompile any applications.

Alternatively it would at least be nice if nVidia and AMD can agree on using the same .def internally, even if it is not yet standardized by Khronos.

Having the same def file that both ATI/AMD and NVIDIA use in order to build their OpenCL.DLL would be a very good idea, specially for us developers, that have to support multiple OpenCL vendors! I am really hoping that this will become a reality sooner rather than later!