ROCm / ROCclr

42 stars 40 forks source link

Hard GLX dependency prevents builds on systems without X #37

Open kwryankrattiger opened 2 years ago

kwryankrattiger commented 2 years ago

There seems to be a hard dependency on Unix platforms to use a GL interface provided by GLX. This causes problems when X is not available, such as when osmesa is the GL provider.

Is there a reason for including the GLX header explicitly here? Should this be guarded differently for cases when glx is not available?

kwryankrattiger commented 2 years ago

device/rocm/rocglinterop.hpp

kwryankrattiger commented 2 years ago
     195    In file included from /tmp/root/spack-stage/spack-stage-hip-5.1.3-2w3ogmhv7xfhtvchd4igen
            feywpmtk2k/spack-src/rocclr/device/rocm/rocglinterop.cpp:26:
  >> 196    /tmp/root/spack-stage/spack-stage-hip-5.1.3-2w3ogmhv7xfhtvchd4igenfeywpmtk2k/spack-src/r
            occlr/cmake/../device/rocm/rocglinterop.hpp:26:10: fatal error: GL/glx.h: No such file o
            r directory
     197       26 | #include <GL/glx.h>
     198          |          ^~~~~~~~~~
     199    compilation terminated.
Mystro256 commented 2 years ago

I believe it's used for GL-CL interop support (hence the filename "rocglinterop"). I believe there's an equivalent HIP-GL interop, but I'm not sure since I've only really worked with OCL.

I don't believe the libraries are currently designed to allow compiling with smaller subsets of functionality, i.e. with no GL interop support.

kwryankrattiger commented 2 years ago

I guess my wondering is why is GLX required all the time. OpenCL is able to interop with EGL or GLX, so if only one is available at build disable the other. Requiring both makes it difficult to build this package on systems that only have one option, ie. headless servers/containers/etc. and impossible to build using headless renders, requiring additional packages needed by X that are otherwise unnecessary.