cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

brevilo
Adept I

OpenCL application deployment on Linux

 

Hi,

 

Background: I want to deploy an OpenCL application on Linux and the target boxes comprise ATI as well as NVIDIA GPUs (not at the same time of course). While the NVIDIA OpenCL installation on those systems works just fine, the ATI equivalent seems a bit odd… Please correct me if I'm wrong...

 

1) It seems that the "OpenCL runtime" (libOpenCL) is not installed with the ATI Catalyst display driver, it's shipped only with the Stream/APP SDK. Is this correct? This would require the SDK to be installed on the target systems, too, while NVIDIA users just need to install the driver (which they have to do anyway) and are ready to go.

 

2) ATI seems to violate so-name conventions regarding the libOpenCL shared library. AFAIK it's common standard that shared libraries bear a so-name including their major version number, like libOpenCL.so.1. The ATI incarnation doesn't. My understanding has been that it should be possible to use a given OpenCL build environment, regardless of the actual vendor, and run the binary (dynamically linked to "a" libOpenCL) on any system that provides the OpenCL runtime components - again regardless of the vendor. If this should be possible, having different so-names for ATI's libOpenCL compared to NVIDIA's libOpenCL precludes that possibility, right?

 

Your thoughts?

 

 

Thanks

 

0 Likes
9 Replies
nou
Exemplar

1) that is correct. but you can try use my package for example. it should work on Debian systems too.

2) libOpenCL.so is universal ICD loader. that mean you can have multple OpenCL implemntations in the system. they will be seen as different platforms with clGetPlatformsIDs(). libOpenCL.so load vendor specific library. in case of AMD it load libatiocl32.so or libatiocl64.so

0 Likes

Originally posted by: nou 

2) libOpenCL.so is universal ICD loader. that mean you can have multple OpenCL implemntations in the system. they will be seen as different platforms with clGetPlatformsIDs(). libOpenCL.so load vendor specific library. in case of AMD it load libatiocl32.so or libatiocl64.so

 

Right, but in that case it's a pitty that ATI doesn't use a "proper" so-name for libOpenCL. The problem is that when you link your app against ATI's libOpenCL.so the loader will look for that exact filename, fine. However, if you build your app linking against NVIDIA's libOpenCL the loader will be told to look for libOpenCL.so.1 (which is the common naming convention). The consequence being that such a binary won't load on ATI systems because of the improper naming and missing symlinks (usually added by ldconfig). This should be fixed IMHO, as well as the fact that the ICD comes only with the SDK, not with driver, and isn't installed in the default library path (i.e. /usr/lib).

 

Cheers

 

0 Likes

brevilo,

CUDA 4.0 is released recently , so it follows the more common naming convention( as enforced by khronos). You will find similar convention with SDK 2.4 when it is released.

Can you confirm whether some code does not work because of this difference in naming conventions. I don't think there should be any problems.

 

0 Likes

the you just create symlink to original libOpenCL.so

0 Likes

Originally posted by: nou the you just create symlink to original libOpenCL.so

 

 

See my previous answer, I know how to workaround all that but I can't expect that from the users of my app.

 

Cheers

0 Likes

thanks for your inputs brevilo.

But AMD must ship the ICD with SDK as it supports both CPU & GPU. On a CPU system you should be able to run openCL without the need of drivers. Isn't it?

Anyways some discussions are going on internally.

0 Likes

Originally posted by: himanshu.gautam thanks for your inputs brevilo.

 

But AMD must ship the ICD with SDK as it supports both CPU & GPU. On a CPU system you should be able to run openCL without the need of drivers. Isn't it?

Fair enough, sounds reasonable.

But how about pursuing both approaches? Why not install the ICD with the Catalyst drivers anyway (in a directly usable way, like OpenGL)? So people using an ATI graphics card are all set, even for OpenCL on CPUs. The CPU-only fraction of users could still get the ICD from a separate package, say, the SDK. IMHO, the GPU fraction of OpenCL users is significantly higher than the CPU fraction anyway (for the time being)...

Originally posted by: himanshu.gautam

 

Anyways some discussions are going on internally.

 

Thanks

0 Likes

Thanks for the suggestion.

0 Likes

Originally posted by: himanshu.gautam brevilo,

 

CUDA 4.0 is released recently , so it follows the more common naming convention( as enforced by khronos). You will find similar convention with SDK 2.4 when it is released.

 

Well, I'm referring to CUDA 3.2 (and probably even older versions) here. So NVIDIA has done it correctly for quite some time...

Originally posted by: himanshu.gautam Can you confirm whether some code does not work because of this difference in naming conventions. I don't think there should be any problems.

 

Consider this, one builds an OpenCL app using NVIDIA's SDK. In this case your app will be linked to libOpenCL.so.1. This app won't load on an ATI system as its default "installation" (the extracted SDK) just contains libOpenCL.so, and that's not even placed in a standard path like /usr/lib (same for the ICD registration via /etc!). This means that without manual intervention one's not able to run the app.

Please keep in mind that I'm talking about app deployment in a heterogeneous environment with ATI and NVIDIA hardware. With a vendor-independent quasi-standard for parallel programming (OpenCL) such scenarios can become common and vendors should properly support that. Compare it to OpenGL: all vendors provide the ICD by just installing the driver, nothing more. ATI would be doing much better following that path with OpenCL, too (as NVIDIA does it already)...

0 Likes