CoreNEURON uses deprecated FindCUDA #520

Activity

1. olupton commented on Apr 20, 2021

   

   olupton

   on Apr 20, 2021

   ContributorAuthor

   More actions

   See also: https://cliutils.gitlab.io/modern-cmake/chapters/packages/CUDA.html
2. alkino commented on May 15, 2021

   

   alkino

   on May 15, 2021

   Member

   More actions

   We have to support both for a long time, minimum version of cmake for CoreNeuron is 3.7.
3. pramodk commented on May 15, 2021

   

   pramodk

   on May 15, 2021

   Collaborator

   More actions

   @alkino : With 8.0 release done, we can bump the minimum requirement to from 3.7 to something more "reasonable".
4. olupton

   added

   build

   gpu

   enhancement

   improvementImprovement over existing implementationImprovement over existing implementation

   and removed

   enhancement

   on Jul 1, 2021
5. olupton commented on Aug 13, 2021

   

   olupton

   on Aug 13, 2021

   ContributorAuthor

   More actions

   In #609 I moved to using CMake's CUDA language support, initially using CMake v3.20. I then added workarounds for older versions back to v3.15.

   An attempted GPU build with CMake v3.10 / CUDA 11.0 / NVHPC 21.7 did not go so well. CMake labels the NVHPC C/C++ compilers as PGI 21.7, but it does not know how to detect the language features that they support. And it does not seem to be possible to distinguish programmatically between the two cases:

   • C++ feature X is known to be unsupported by PGI/NVHPC version Y
   • No test is implemented for C++ feature X for PGI/NVHPC compilers

   The result is that the check introduced in #591 fails. If this test is disabled for PGI/NVHPC, we hit a similar issue with the catch2 submodule of NEURON. If we add workarounds for both of these (I just skipped the check for CoreNEURON and manually kludged CMAKE_CXX_COMPILE_FEATURES for catch2, but it's not important) then there is a further issue:

   [19/199] Linking CXX executable bin/lfp_test_bin
   FAILED: bin/lfp_test_bin
   : && /gpfs/bbp.cscs.ch/home/olupton/spack/opt/spack/linux-rhel7-x86_64/gcc-9.3.0/nvhpc-21.7-j4zbmu/Linux_x86_64/21.7/compilers/bin/nvc++  -tp=haswell -acc -gpu=cuda11.0,cc60,cc70 --diag_suppress 161,177,550 -mp   -g  -O2  -cuda external/coreneuron/tests/unit/lfp/CMakeFiles/lfp_test_bin.dir/lfp.cpp.o external/coreneuron/tests/unit/lfp/CMakeFiles/lfp_test_bin.dir/cmake_device_link.o  -o bin/lfp_test_bin -L/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/externals/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/hpe-mpi-2.22.hmpt-r52ypu/lib  -L/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/externals/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/cuda-11.0.2-kb4wci/targets/x86_64-linux/lib/stubs  -L/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/externals/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/cuda-11.0.2-kb4wci/targets/x86_64-linux/lib  -L/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/compilers/2021-01-06/linux-rhel7-x86_64/gcc-4.8.5/gcc-9.3.0-45gzrp/lib -Wl,-rpath,/gpfs/bbp.cscs.ch/home/olupton/nrn/build_ollimod2c/bin/x86_64:/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/externals/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/hpe-mpi-2.22.hmpt-r52ypu/lib:/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/libraries/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/boost-1.73.0-ell6js/lib -lpthread -lmpi++ -lmpi /gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/libraries/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/boost-1.73.0-ell6js/lib/libboost_unit_test_framework-mt.so lib/libcoreneuron.a bin/x86_64/libcorenrnmech.a -lpthread -lmpi lib/libcudacoreneuron.a -lrt -lcudart && :
   external/coreneuron/tests/unit/lfp/CMakeFiles/lfp_test_bin.dir/cmake_device_link.o: In function `__cudaRegisterLinkedBinary_45___external_coreneuron_tests_unit_lfp_lfp_cpp':
   /gpfs/bbp.cscs.ch/ssd/slurmTmpFS/olupton/2468239/tmpxft_000422d1_00000000-3_cmake_device_link.reg.c:2: undefined reference to `__fatbinwrap_45___external_coreneuron_tests_unit_lfp_lfp_cpp'
   pgacclnk: child process exit status 1: /usr/bin/ld
   

   which is presumably because of

   The CUDA_RESOLVE_DEVICE_SYMBOLS target property is now supported on shared library, module library, and executable targets. Previously it was only honored on static libraries.

   from the v3.14 release notes, but the changes of #609 rely on setting this property on executable targets. This looks more awkward to work around.
6. alexsavulescu

   closed this as completedin #609on Aug 13, 2021