Open casparvl opened 6 years ago
boegel
commented
6 years ago @casparvl I would indeed opt for option 2, since option 3 is not going to be pretty and it's specific to Blender. We could define a custom easyconfig parameter to control the removal of the old GL headers in the CUDA easyblock, so people can disable the removal of the old GL header if that's a problem for them (as opposed to hardcoding the removal without any way to opt out)?
casparvl
commented
6 years ago @boegel Making it optional sounds like an elegant way to do it to me. The next challenge would then be which default makes the most sense.
On the one hand, "no removal" will give you the CUDA installation that is most similar to a manual CUDA install. On the other hand, removing it by default, you will get the most clear error message if you go wrong (worst case scenario, a user gets a 'missing GL/something.h' error when trying to compile CUDA examples, but that's quite easy to pin down). The errors of software picking up the wrong GL headers are much more subtle...
Problem:
When building Blender with CUDA support with our own custom EasyConfig (attached as .txt file since github doesn't allow attaching .eb?), Blender-2.79b-foss-2017b-Python-3.6.3-CUDA-9.0.176.txt the build fails with
In file included from /scratch/shared/jenkins/regression/build/Blender/2.79b/foss-2017b-Python-3.6.3-nvidia/blender-2.79b/intern/ghost/intern/GHOST_ContextGLX.h:41:0, from /scratch/shared/jenkins/regression/build/Blender/2.79b/foss-2017b-Python-3.6.3-nvidia/blender-2.79b/intern/ghost/intern/GHOST_WindowX11.cpp:51: /scratch/shared/jenkins/regression/build/Blender/2.79b/foss-2017b-Python-3.6.3-nvidia/blender-2.79b/extern/glew/include/GL/glxew.h:1758:29: error: expected initializer before glxewInit GLEWAPI GLenum GLEWAPIENTRY glxewInit ();This installation worked fine with earlier versions of the CUDA EasyBlock up until this change, which prepended the CUPTI headers to the CPATH https://github.com/easybuilders/easybuild-easyblocks/pull/1306Cause:
The CUPTI header directory also contains GL headers (only headers, no libs). These headers are pretty old, and incompatible with the GL headers & libs that are shipped with Blender. It seems the blender installation starts picking up the GL headers in the CUPTI directory though. A manual installation of Blender, where the CUPTI header directory was removed from the CPATH, succeeded.
Potential solutions
1) Don't have the CUDA module prepend extras/CUPTI/include CPATH (upside: old GL headers are not picked up anymore. Downside, the actual CUPTI headers for profiling are also not picked up so user would have to include these manually).
2) Have the CUDA EasyBlock remove (just) the old GL headers from the extras/CUPTI/include path (downside: not default CUDA installation, examples may not build. Upside: you can leave CUPTI headers in CPATH)
3) 'hack' the Blender EasyConfig (or a Blender EasyBlock) to do a tricky thing to get extras/CUPTI/include out of the CPATH, e.g. in the prebuildstep or something. Upside: CUPTI headers can remain prepended in CPATH in the CUDA module, and the CUDA examples will build 'out of the box'. Downside: feels very dirty and other software MAY run into the same, old GL headers.
Proposed solution Discussion on the mailinglist seemed to opt for option 2). It is nice to keep the CUPTI headers in the CPATH as this is convenient for users, which discards 1). 3) is an ugly solution, especially since this problem could occur with other builds that depend on the GL headers as well. Thus, 2) seems the best way to go, the only impact being that the CUDA examples might not work out of the box as these need the GL headers.