cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

stefan_w
Journeyman III

function naming in OpenCL.dll

I wrote a little loader for the OpenCL.dll which works perfectly well with NVIDIA, however it fails with the OpenCL.dll provided by AMD.

If open the DLL with Dependency Walker, I see that all function names have an underscore prefixed and an @ postifxed.

Will this be fixed? Because this makes it a lot harder to write a loader that works with AMD and NVIDIA.

Linking with OpenCL.lib is not an option, because the application should also work if no OpenCL.dll is present.

0 Likes
11 Replies
omkaranathan
Adept I

Originally posted by: stefan_w

Will this be fixed? Because this makes it a lot harder to write a loader that works with AMD and NVIDIA.

The binary distribution format across vendors is an ongoing discussion at Khronos. Khronos is working on an ICD model much like OpenGL so that you will only link against a standard library which the vendors will then plugin to.

0 Likes

I just noticed this problem aswell.

First question that leaps to mind: What were you thinking!?

Why do you use cdecl? The standard convention for Windows is stdcall. If you took a moment to study OpenGL and OpenAL, you will see that they both use stdcall on Windows aswell. The obvious choice for OpenCL therefore should also be stdcall.

nVidia uses stdcall, but because you for some incomprehensible reason didn't go with the common standard, your SDK is now binary incompatible with nVidia's.

I also find it very strange that Khronos didn't pick this up during conformance testing. They should have noticed right away that nVidia's and your SDKs were using different calling conventions, and they'd never play nice on a binary level.

I really don't think that Khronos will decide in your favour when they will standardize the calling convention, because it seems obvious that you'd want OpenGL, OpenAL and OpenCL to all be consistent. So you might aswell change it now, and give us developers a break. You've held up OpenCL long enough already.

0 Likes

Scali,
Are you sure you are using the correct header files? In include/CL/cl_platform.h it defines __CL_CALL as this:
# define __CL_CALL __stdcall

Please verify that you are using the correct header files as we are following what was agreed upon for OpenCL w/ Khronos.
0 Likes

I'm talking about the OpenCL.dll that is included in the SDK, in the x86\bin directory.

As the opening post says, the names all have an underscore prefix and an @NN suffix with NN being the number of bytes in the arguments.

OpenGL32.dll, OpenAL32.dll and nVidia's OpenCL.dll all use a different calling convention, they don't have a leading underscore, and they don't have the @NN suffix either.

Seems I may have mixed up stdcall and cdecl, but the point remains... (or at least, the exported symbols just aren't the fully decorated stdcall names in the nVidia DLL, as they usually aren't).

Hence, if I link to nVidia's DLL, I cannot use your DLL and vice versa. Your DLL is inconsistent with OpenGL and OpenAL, nVidia's isn't.

I want to be able to develop an application that will just work, regardless of whether you have the nVidia or the AMD DLL.

If you look at nVidia's cl_platform.h, they have:
#define CL_API_CALL

(So nothing after it, no __stdcall).

In fact, their header even reads:

* Copyright (c) 2008-2009 The Khronos Group Inc.

Yours seems to be very different, even though they should be the same for the most part.

Edit: In fact, the problem might not be the calling convention itself, but rather the naming convention. You should have used a .def file when creating the OpenCL.dll?

Edit 2: And after poking around in nVidia's code, it seems that they indeed do NOT use stdcall, there is no callee stack cleanup. So it seems that you both need to go back to the drawing board.

0 Likes

Scali,
We are following the correct naming convention for __stdcall according to microsoft as specified here:
http://msdn.microsoft.com/en-us/library/zxk0tw93.aspx

0 Likes

True, but that part only covers stdcall within object modules.

When you're using a DLL, you have to deal with exporting and importing symbols by name and/or ordinal. If using a def file, you can ensure that symbol names and ordinals will always match.

As I say, you both have get back to the drawing board, and figure out a common way to export symbols and a common calling convention.

If you ask me, nVidia got the exported symbols right, you got the calling convention right. Put the two together and they match what OpenGL does. All it takes is a simple recompile, and we'd have two compatible OpenCL.dlls. That would make us developers very happy. Sure, a complete ICD model would be better, but let's take it one step at a time, get that OpenCL ball rolling.

0 Likes
mael
Journeyman III

Hello,

I'm using OpenCL from another language (Delphi). When importing the API-functions from OpenCL.dll the name-mangling requires me to specify the mangled name instead of the real function name. Since name-mangling is compiler dependent and it differs from the function names found in the header files it makes importing more fragile than necessary.

Please disable it by using something like

#ifdef __cplusplus
extern "C" {
#endif

// exports go here
#ifdef __cplusplus
}
#endif

Regards, Maël Hörz

0 Likes
Scali
Journeyman III

I've posted the issue on the Khronos messageboard aswell:

http://www.khronos.org/message_boards/viewtopic.php?f=28&t=2114

nVidia has responded and says they will change their SDK to stdcall. That's at least part of the problem. Hopefully we can also get everyone to agree on the exported symbols. Then again, when the calling convention is correct, I suppose a bit of hex editing can fix the symbol names, so if nVidia and AMD won't fix it, I will

0 Likes

The current SDK(beta4) has __stdcall calling convention for Windows and also the naming convention for API functions has changed from decorated to undecorated names.

0 Likes

Originally posted by: omkaranathan The current SDK(beta4) has __stdcall calling convention for Windows and also the naming convention for API functions has changed from decorated to undecorated names.

Ah yes, when you originally posted this, you didn't have the "undecorated names"-part in it, so I missed that.

nVidia has also said that they will recompile their SDK to stdcall. Let's hope they will also keep the undecorated names, and then we may finally have something compatible

Thanks for addressing the problem so quickly.

0 Likes
mael
Journeyman III

I can confirm beta 4 fixes the issues with name mangling/decoration.

0 Likes