4 Replies Latest reply on Nov 23, 2015 2:52 AM by fesc2000

    PLEASE fix Linux opengl/opencl interop

    fesc2000

      Hi,

       

      I have posted this issue years (?) ago and even opened a ticket at the debian fglrx packet maintainer.

      Whatever the cause, it is STILL not fixed:

       

      When using opengl/opencl interop, the opencl library apparently dlopens libGL.so, whereas my application is linked against libGL.so.1.

      But /usr/lib/x86_64-linux-gnu/libGL.so and libGL.so.1 are different binaries.

      This eventually leads to a crash (X error).

       

      Every time i do an upgrade of packages, i have to manually link libGL.so to libGL.so.1 so that my application works again.

       

      PLEASE AMD: You are not supposed to dlopen("libGL.so"), use dlopen("libGL.so.1")!

      By the way, why do you have to open libGL again at all? If i have an application does gl/cl interop than it has to be linked to the correct libGL anyway. Otherwise it couldn't provide the context information ...

       

      Regards,

       

      Felix.

        • Re: PLEASE fix Linux opengl/opencl interop
          tzachi.cohen

          Dear Felix,

           

          I can assure you that AMD OCL is dlOpening "libGL.so.1". It is required to gain access to a private CL-GL interface exported from GL.

           

          Tzachi

            • Re: PLEASE fix Linux opengl/opencl interop
              fesc2000

              Hi Tzachi,

               

              Hmm, but i know that it once did. Maybe i'm still using an old version (fglrx-driver (1:14.9+ga14.201-2)).

              Two weeks ago i did an update on debian sid, and the error again, and i had to fix it by linking libGL.so to libGL.so.1.

               

              I'll probably try the official libraries from the AMD site. Sorry for the fuss if it's fixed.

               

              - Felix.

            • Re: PLEASE fix Linux opengl/opencl interop
              nibal

              fesc2000 wrote:

               

              Hi,

               

              I have posted this issue years (?) ago and even opened a ticket at the debian fglrx packet maintainer.

              Whatever the cause, it is STILL not fixed:

               

              When using opengl/opencl interop, the opencl library apparently dlopens libGL.so, whereas my application is linked against libGL.so.1.

              But /usr/lib/x86_64-linux-gnu/libGL.so and libGL.so.1 are different binaries.

              This eventually leads to a crash (X error).

               

              Every time i do an upgrade of packages, i have to manually link libGL.so to libGL.so.1 so that my application works again.

               

              PLEASE AMD: You are not supposed to dlopen("libGL.so"), use dlopen("libGL.so.1")!

              By the way, why do you have to open libGL again at all? If i have an application does gl/cl interop than it has to be linked to the correct libGL anyway. Otherwise it couldn't provide the context information ...

               

              Regards,

               

              Felix.

              LigGL from linux calls some raster function, that ubuntu installation doesn't provide. It is broken, and a well known libGL bug. I use the fgrlx libGL.so for all my needs. How do you figure that using libGL.so.1 will fix your library paths? libGL.so is just a link. It sounds that you are asking amd to hardwire the library path in their applications. Doesn't sound too good :-(

                • Re: PLEASE fix Linux opengl/opencl interop
                  fesc2000

                  Well, i'm using debian together with the fglrx package.

                  In this situation libGL.so and libGL.so.1 is a different binary (in /usr/lib/x86_64-linux-gnu), for what reason ever. I'm linking my application with -lGL, and ldd says it links against libGL.so.1.

                  This works fine with OpenCL as long as i don't use interop. Then i see (with dltrace/strace) that at some point libGL.so gets loaded, and the application eventually crashes with an X error (probably because the GL context information is incompatible).

                  If i move the original libGL.so away and link it to libGL.so.1 everything works fine, up to the next time mesa/glx gets an update and i have to redo this procedure.

                  This has been the case for years now.

                   

                  I addressed this to the Debian package maintainer, and the usual answer is that applications should dlopen "so.x" instead of "so".

                   

                  I'm not the only one with this issue, see  Bug 601 – Never dlopen libGL.so, but rather libGL.so.1

                   

                  - Felix