Open kwryankrattiger opened 2 years ago
device/rocm/rocglinterop.hpp
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.
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.
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.
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?