cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

nomac
Journeyman III

Another reason for clGetPlatformIDs to fail

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.

0 Likes
1 Reply
genaganna
Journeyman III

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.

0 Likes