Migrate to FindCUDAToolkit.cmake

[SomeoneSerge]

Main idea

NVIDIA considers FindCUDA.cmake (find_package(CUDA)) deprecated: https://docs.nvidia.com/cuda/cuda-installation-guide-linux/#importing-tarballs-into-cmake. The common approach to consume cudatoolkit today is to use FindCUDAToolkit.cmake (find_package(CUDAToolkit COMPONENTS cudart cublas ...)).

Aside from FindCUDA being obsolete, there are notable differences between the modules: e.g. FindCUDAToolkit.cmake allows its CUDAToolkit_ROOT variable to take the form of a list of paths, and this way it supports splayed installations of cudatoolkit, where different components (cudart, cublas, ...) may reside in different prefixes (as is the case e.g. in nixpkgs)

Other sci-comp projects are moving away from FindCUDA.cmake too, e.g. pytorch/pytorch#76082

Thanks!

Anything else?

No response

[davisking]

Yeah, we will update eventually. We are on cmake 3.8 right now and that's a feature only in 3.17 or newer. Lots of dlib users update their tooling slowly, so dlib has to update slowly too :|

[jakirkham]

Would it make sense to have branch logic for these 2 cases? Namely

• If CMake is 3.17+, use find_package(CUDAToolkit)
• If CMake is older, fallback to find_package(CUDA)

Maybe another option would be to vendor FindCUDAToolkit.cmake

cc @robertmaynard (in case you have thoughts/suggestions here)

[SomeoneSerge]

I like the idea of introducing FindCUDAToolkit.cmake support earlier. I find branching preferable to vendoring because it's a risk of divergence. E.g. pytorch vendors a copy, but their API already deviates from kitware's (the former doesn't accept lists in CUDAToolkit_ROOT). There are projects that went with branching too (list tbd)

[robertmaynard]

Replacing FindCUDA fully with FindCUDAToolkit will require also switching from the previous use of cuda_add_library ( and CUDA_NVCC_FLAGS ) to the first class CUDA language support in CMake ( add_library(example source.cu) ).

This kind of change makes it harder to support switching between pre and post 3.17. I would recommend making a clean break when possible, especially given that CMake 3.27 introduces a policy to remove FindCUDA entirely.

CMake does offer apt.kitware.com for ubuntu users that want to to get the latest version of CMake on older Ubuntu releases. The CMake binaries from cmake.org are built to support seriously old distro's as well, so they can be dropped onto machines which only provide 3.8 via the official package manager.

[Tobias-Fischer]

See conda-forge/dlib-feedstock#83 for a patch that uses FindCUDAToolkit.cmake (more specifically, https://github.com/conda-forge/dlib-feedstock/blob/cf9148326a7ad74c1dd519c2d3d5dc2912f9697c/recipe/use_new_cudatoolkit.patch)

[davisking]

Yeah if it can just branch on cmake version without being a big mess that would be cool. I personally have newer cmake on my system. Maybe we could start to require cmake 3.17 for dlib. It bothers me though that, for example, Ubuntu 22.04 then wouldn't work with its version of cmake and I know plenty of people are still on stuff that old.

Is this a big deal to not have the newer thing right now?

[Tobias-Fischer]

CUDA12 is (as far as I know) not supported with the old FindCUDA.

[robertmaynard]

Ubuntu 22.04 then wouldn't work with its version of cmake and I know plenty of people are still on stuff that old.

Ubuntu 22.04 provides CMake 3.22.
Ubuntu 20.04 provides CMake 3.16
Ubuntu 18.04 provides CMake 3.10

The upside is for 20.04 and 22.04 the apt.kitware.com repository can be used to get latest cmake releases ( officially blessed by CMake ). Ubuntu 18.04 users would need to download the pre-build cmake binaries and install them manually.

[davisking]

Uh, yeah, alright. I've come around. It's not like people have to pull the latest dlib if they are on an old OS anyway and it would be real convenient for multiple reasons to upgrade CMake. So one of you want to put up a PR that switches to cleaner cuda cmake rules and uses cmake 3.17? :)

[Tobias-Fischer]

I don't have the capacity at the moment, but basically everything required is in https://github.com/conda-forge/dlib-feedstock/blob/cf9148326a7ad74c1dd519c2d3d5dc2912f9697c/recipe/use_new_cudatoolkit.patch (just needs a bump of the cmake_minimum_version).

[davisking]

Well, I mean, is it really all in that patch? Seems like you are saying it's not if it takes time? :)

…

On Tue, Jan 16, 2024 at 11:59 PM Tobias Fischer ***@***.***> wrote: I don't have the capacity at the moment, but basically everything required is in https://github.com/conda-forge/dlib-feedstock/blob/cf9148326a7ad74c1dd519c2d3d5dc2912f9697c/recipe/use_new_cudatoolkit.patch (just needs a bump of the cmake_minimum_version). — Reply to this email directly, view it on GitHub <#2833 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPYFR3MKTFNBWYJUJJMEUDYO5LDDAVCNFSM6AAAAAA2RU64ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUHE2DGMZYG4> . You are receiving this because you commented.Message ID: ***@***.***>

[Tobias-Fischer]

Yes, it’s all in the patch except for setting the correct minimum cmake version

[pfeatherstone]

I did have a branch at some point in the past that cleaned up all of dlib's cmake stuff including CUDA. I can try to revive that at some point.

[davisking]

Yeah. I think I'm fine with switching the required version of cmake to a higher version. So if there is some good stuff to be had by doing that then send me a PR :)