11 Replies Latest reply on Oct 24, 2009 2:40 PM by mael

    function naming in OpenCL.dll

    stefan_w

      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.

        • function naming in OpenCL.dll
          omkaranathan

           

          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.

            • function naming in OpenCL.dll
              Scali

              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.

            • function naming in OpenCL.dll
              MicahVillmow
              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.
                • function naming in OpenCL.dll
                  Scali

                  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.

                • function naming in OpenCL.dll
                  MicahVillmow
                  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

                    • function naming in OpenCL.dll
                      Scali

                      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.

                        • function naming in OpenCL.dll
                          mael

                          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