3 Replies Latest reply on Feb 7, 2012 6:47 AM by nou

    Compatability libOpenCL* among platform vendors

    settle

      When I go to install the AMD APP SDK and the Intel OpenCL SDK or the NVIDIA CUDA SDK, each SDK wants to overwrite the other's libOpenCL* shared libraries, but none of them are binary identical pairs.  How can I be certain that all these OpenCL SDKs can play nicely together and won't cause problems?  Shouldn't they all include the same standard libOpenCL* shared libraries?  This goes for libOpenGL* as well.  However, the issue is also that should these files really go in /usr/lib, /usr/lib32, or /usr/lib64 in the first place?  Why not leave them where they're installed in /opt/AMDAPP and just add them to the correct paths?  That way you can easily update and revert back to older versions with confidence.  The /usr/bin and /usr/lib directories are generally reserved for system managed installs via yum, zypper, apt, etc.

       

      Also, is the perl install script really necessary?  Didn't AMD use a bash script before in order AMD APP SDK (or ATI Stream SDK) versions, which worked great and was easy to read and change install directory?  This has to be the worst formatted perl script I've seen and not as easy to modify.

        • Compatability libOpenCL* among platform vendors
          nou

          source for libOpenCL.so are maintained by khronos. both vendors are compiling it from this sources so they don't get binary identical files. but they should be compatble. many people have AMD CPU OpenCL and nVidia GPU and they play nicely.

           

          you can just extract archive into /opt and set path manualy if you don't like that script.

          1 of 1 people found this helpful
            • Re: Compatability libOpenCL* among platform vendors
              settle

              Thank you nou.

               

              I recalled one problem that did happen before though with multiple vendor OpenCL SDKs.  The header files are not always compatible.  Each vendor adds things into their headers before they actually make their way into the Khronos hosted headers.  This can get annoying if I forget when I go to compile.

               

              Ah, one last question.  Does one still have to set the DISPLAY and COMPUTE system variables when running code on a remote machine?  It was an issue awhile ago and I don't know if it's still necessary or if they've fixed something internally in the driver.  If someone could say for sure I'm be grateful!