Autodetection of CUDA arch sometimes fails to configure

When build as part of VTK, we have a report[1] on Gentoo Linux that autodetection of the CUDA architecture fails in some cases, i.e. when -DVTKm_CUDA_Architecture=native is passed to cmake. If one the named architectures is used, e.g. turing, maxwell, etc., the configuration succeeds.

Any ideas?

[1] https://bugs.gentoo.org/835659

When VTKm_CUDA_Architecture is set to native, the CMake script attempts to build and run a small program named VTKmDetectCUDAVersion.cu to query the CUDA card attached to the build computer. Likely there is something going wrong with either the build or the execution of that program.

Try looking through the CMakeFiles/CMakeOutput.log file created by CMake when it is run and search for VTKmDetectCUDAVersion. The output of the compile and/or build might give a clue about what is going on.

Thanks for your feedback.

The logfile doesn't contain the string VTKm or vtkm.

Grepping for CUDA however, outputs many lines of calls to some build tools (gcc, cc1plus, as, etc.) where -D__CUDA_ARCH__=520 -D__CUDA_ARCH_LIST__=520 are passed along. No line passes any other arch id, only checks for CUDA compatibility 5.2 are used in the logfile. Would it be possible the check for this specific arch has some issues and drops out from the check early? If it's useful, I can upload the CMakeOutput.log file here.

In ${BUILD_DIR}/ThirdParty/vtkm/vtkvtkm/vtk-m there's an a.out binary, which when called outputs a string, which matches the printf statement in the VTKmDetectCUDAVersion.cu file. In my case it's --generate-code=arch=compute_75,code=sm_75; which is correct. So it looks like the build of the programm works and the program itself does work as well.

Yes, posting your CMakeOutput.log as well as your CMakeCache.txt here would help. It would be best if these came from a clean build attempt. That is, from calling cmake for the first time (with the -DVTKm_ENABLE_CUDA=ON -DVTKm_CUDA_Architecture=native flags). CMake will skip the whole test if it detects it has been run before.

Also, it would be helpful if you could report the version of CMake and the version of VTK-m you are using.

I'm using CMake 3.23.0 and the vtk-m version included in VTK-9.0.3. The issue also happens with VTK-9.1.0.

See attached the CMakeOutput.log and CMakeCache.txt files. CMake has been called as

cmake -C /var/tmp/portage-ondisk/portage/sci-libs/vtk-9.0.3-r5/work/vtk-9.0.3_build/gentoo_common_config.cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DVTK_BUILD_ALL_MODULES=OFF -DVTK_BUILD_DOCUMENTATION=OFF -DVTK_BUILD_EXAMPLES=OFF -DVTK_ENABLE_KITS=OFF -DVTK_ENABLE_REMOTE_MODULES=OFF -DVTK_DATA_STORE=/var/tmp/portage-ondisk/portage/sci-libs/vtk-9.0.3-r5/work/VTK-9.0.3/.ExternalData -DVTK_GROUP_ENABLE_Imaging=DEFAULT -DVTK_GROUP_ENABLE_Qt=DEFAULT -DVTK_GROUP_ENABLE_Rendering=WANT -DVTK_GROUP_ENABLE_StandAlone=WANT -DVTK_GROUP_ENABLE_Views=DEFAULT -DVTK_GROUP_ENABLE_Web=DEFAULT -DVTK_MODULE_ENABLE_VTK_vtkm=WANT -DVTK_MODULE_ENABLE_VTK_AcceleratorsVTKm=WANT -DVTK_PYTHON_VERSION=3 -DVTK_RELOCATABLE_INSTALL=ON -DVTK_USE_CUDA=ON -DVTK_USE_EXTERNAL=ON -DVTK_USE_MPI=OFF -DVTK_USE_TK=OFF -DVTK_USE_X=ON -DVTK_VERSIONED_INSTALL=ON -DVTK_WRAP_JAVA=OFF -DVTK_WRAP_PYTHON=ON -DVTKm_CUDA_Architecture=native -DVTK_MODULE_ENABLE_VTK_IOGeoJSON=WANT -DVTK_SMP_IMPLEMENTATION_TYPE=OpenMP -DVTKm_ENABLE_OPENMP=ON -DVTK_MODULE_USE_EXTERNAL_VTK_pegtl=OFF -DVTK_ENABLE_WRAPPING=ON -DPython3_EXECUTABLE=/usr/bin/python3.10 -DVTK_PYTHON_SITE_PACKAGES_SUFFIX=lib/python3.10/site-packages -DVTK_MODULE_USE_EXTERNAL_VTK_libharu=OFF -DVTK_MODULE_ENABLE_VTK_IOExportGL2PS=WANT -DVTK_MODULE_USE_EXTERNAL_VTK_gl2ps=ON -DVTK_MODULE_USE_EXTERNAL_VTK_glew=ON -DVTK_MODULE_USE_EXTERNAL_VTK_libproj=ON -DVTK_BUILD_TESTING=OFF -DVTK_FORBID_DOWNLOADS=ON -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage-ondisk/portage/sci-libs/vtk-9.0.3-r5/work/vtk-9.0.3_build/gentoo_toolchain.cmake /var/tmp/portage-ondisk/portage/sci-libs/vtk-9.0.3-r5/work/VTK-9.0.3

CMakeOutput.log CMakeCache.txt