1 Reply Latest reply on Feb 18, 2011 5:10 AM by genaganna

    Another reason for clGetPlatformIDs to fail

    nomac
      Proceed when you get CL_PLATFORM_NOT_FOUND_KHR (-1001), on Linux

      Hello everyone,

      I finally figured out why OpenCL programs fail to run on the cluster I use. So If you also get CL_PLATFORM_NOT_FOUND_KHR (-1001) and clGetPlatformIDs() fails, even though you have a a correct ICD registration, you might miss some library on which the client driver libatiocl32.so or libatiocl64.so depends.

      The problem is, that the client driver is somehow loaded at runtime, and it fails in silence if a library is missing or the ICD registration (which is a textfile that specifies to load libatiocl[32|64].so) is wrong. Normally, you would get an error from the operating system if a dynamically linked library like libOpenCL is missing, but the client driver and it's loading mechanism introduces a kind of indirection.

      In my case libGLU was missing on the cluster's nodes.

      So If your ICD registration is correct and you encouter the type of failure above, you should check the output of (analog for 32 bit):

       

      ldd $ATISTREAMSDKROOT/lib/x86_64/libatiocl64.so


      which reported:

       

          libdl.so.2 => /lib64/libdl.so.2 (0x00002ad7a2789000)
          libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002ad7a298d000)
          libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002ad7a2c99000)
          libGLU.so.1 => not found
          librt.so.1 => /lib64/librt.so.1 (0x00002ad7a2f14000)
          libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002ad7a311d000)
          libm.so.6 => /lib64/libm.so.6 (0x00002ad7a341e000)
          libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002ad7a36a1000)
          libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ad7a38af000)
          libc.so.6 => /lib64/libc.so.6 (0x00002ad7a3aca000)
          /lib64/ld-linux-x86-64.so.2 (0x0000003961e00000)
          libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002ad7a3e1d000)
          libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00002ad7a401f000)
          libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002ad7a4225000)
          libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002ad7a4436000)

          libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002ad7a463b000)



      Every "not found" means a missing library, against which the driver is linked. After identifying the missing library you only need to find the corresponding package for your distribution and install it. For example:

       

      yum install mesa-libGLU.x86_64


      on CentOS, RedHat or Fedora.

      I hope this post will help someone not to waste as many hours as I did by narrowing down the problem and fixing it.

      It would also be a great idea for the AMD developers to add some helpfull error message to the whole ICD loading mechanism.

        • Another reason for clGetPlatformIDs to fail
          genaganna

           

          Originally posted by: nomac Hello everyone,

           

          I finally figured out why OpenCL programs fail to run on the cluster I use. So If you also get CL_PLATFORM_NOT_FOUND_KHR (-1001) and clGetPlatformIDs() fails, even though you have a a correct ICD registration, you might miss some library on which the client driver libatiocl32.so or libatiocl64.so depends.

           

          The problem is, that the client driver is somehow loaded at runtime, and it fails in silence if a library is missing or the ICD registration (which is a textfile that specifies to load libatiocl[32|64].so) is wrong. Normally, you would get an error from the operating system if a dynamically linked library like libOpenCL is missing, but the client driver and it's loading mechanism introduces a kind of indirection.

           

          In my case libGLU was missing on the cluster's nodes.

           

          So If your ICD registration is correct and you encouter the type of failure above, you should check the output of (analog for 32 bit):

           

           

          ldd $ATISTREAMSDKROOT/lib/x86_64/libatiocl64.so


           

          which reported:

           

           

              libdl.so.2 => /lib64/libdl.so.2 (0x00002ad7a2789000)     libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002ad7a298d000)     libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002ad7a2c99000)     libGLU.so.1 => not found     librt.so.1 => /lib64/librt.so.1 (0x00002ad7a2f14000)     libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002ad7a311d000)     libm.so.6 => /lib64/libm.so.6 (0x00002ad7a341e000)     libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002ad7a36a1000)     libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ad7a38af000)     libc.so.6 => /lib64/libc.so.6 (0x00002ad7a3aca000)     /lib64/ld-linux-x86-64.so.2 (0x0000003961e00000)     libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002ad7a3e1d000)     libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00002ad7a401f000)     libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002ad7a4225000)     libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002ad7a4436000)

           

              libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002ad7a463b000)



           

          Every "not found" means a missing library, against which the driver is linked. After identifying the missing library you only need to find the corresponding package for your distribution and install it. For example:

           

           

          yum install mesa-libGLU.x86_64


           

          on CentOS, RedHat or Fedora.

           

          I hope this post will help someone not to waste as many hours as I did by narrowing down the problem and fixing it.

           

          It would also be great idea for the AMD developers to add some helpfull error message to the whole ICD loading mechanism.

           

          nomac,

                  Thank you very much for sharing this with us. We will document this.