CUDA 12 ships with Thrust/CUB 2.0. It's a new major release, but fortunatley we do not use any of the removed / breaking changes. It does add libcudacxx as a depenceny, which is distributed with CUDA, so 12.0 builds are fine.
CUDA 11.x builds are less fine, where if we clone thrust 2.0 the libcudacxx submodule causes path length issues when cloning the submodule on windows for the standalone example, and the current rc builds error in 11.0 atleast.
We could move to Thrust 2.0 everywhere, once there is a thrust 2.x release on github, but will need to workaround some issues.
- path length on windows for libcudacxx submodule - migth be solvable with a git config option?
- CUDA 11.0 compilation errors - might just need the non-rc release?
- CMake re-finding issues - if Thrust 1.x is found, it may still define a target, which prevents subsequent finding of a cloned 2.0 from perfoming a bunch of cmake, so the first configure fails but a reconfigure passes.
- Horrible solution would be to call cmake on an ephemeral CMakeLists.txt which finds Thrust 2.x, and use the results of that to decide what to do in the actual CMakeLists.txt.
Or we can just keep with 1.16+, and if CUB/Thrust in a future release cause breakages with our usage we can just #ifdef around it? I.e. make it a future problem rather than trying to pre-empt it.
Edit
As of October 2023, Thrust, cub and libcudacxx have been combined into CCCL. We might need to make changes so we can leverage this as the thrust/cub interfaces and cmake evovle.
https://github.com/NVIDIA/cccl
CCCL is compatible with older cuda's.
I.e. we can't hard pin to a particualr version and stay supported, will need to check the version, and not fetch if cuda's is newer to stay supported. We roughly do this with thrust currently, but some version's of thrust's cmake didn't get along with being unfound iirc.
Users who want to stay on the cutting edge of CCCL development are encouraged to use CCCL from GitHub. Using a newer version of CCCL with an older version of the CUDA Toolkit is supported, but not the other way around. For complete information on compatibility between CCCL and the CUDA Toolkit, see our platform support.
- The latest version of CCCL is backward compatible with the current and preceding CTK major version series
- The latest version of CCCL is backward compatible with the current and preceding CTK major version series
CCCL is never forward compatible with any version of the CTK. Always use the same or newer than what is included with your CTK.
- Minor version CCCL upgrades won't break existing code, but new features may not support all CTK versions
However due to cuda's magic include dirs, can't isystem it (I sketchily managed this in the past with cub/thrust, but think I had to remove that when the thrust cmake changed at one point).
Note Ensure to use -I and not -isystem in order to ensure the cloned headers are found before those included in the CUDA Toolkit
Not all features will work with CUDA 11 either (those that depend on C++20), but we dont' want those anyway.
As this changes the cmake target(s) we link against, this will also prevent issues with thrust 1 vs 2 cmake suggested above, by always requiring CCCL.
CUDA 12 ships with Thrust/CUB 2.0. It's a new major release, but fortunatley we do not use any of the removed / breaking changes. It does add libcudacxx as a depenceny, which is distributed with CUDA, so 12.0 builds are fine.
CUDA 11.x builds are less fine, where if we clone thrust 2.0 the libcudacxx submodule causes path length issues when cloning the submodule on windows for the standalone example, and the current rc builds error in 11.0 atleast.
We could move to Thrust 2.0 everywhere, once there is a thrust 2.x release on github, but will need to workaround some issues.
Or we can just keep with 1.16+, and if CUB/Thrust in a future release cause breakages with our usage we can just #ifdef around it? I.e. make it a future problem rather than trying to pre-empt it.
Edit
As of October 2023, Thrust, cub and libcudacxx have been combined into CCCL. We might need to make changes so we can leverage this as the thrust/cub interfaces and cmake evovle.
https://github.com/NVIDIA/cccl
CCCL is compatible with older cuda's.
I.e. we can't hard pin to a particualr version and stay supported, will need to check the version, and not fetch if cuda's is newer to stay supported. We roughly do this with thrust currently, but some version's of thrust's cmake didn't get along with being unfound iirc.
However due to cuda's magic include dirs, can't isystem it (I sketchily managed this in the past with cub/thrust, but think I had to remove that when the thrust cmake changed at one point).
Not all features will work with CUDA 11 either (those that depend on C++20), but we dont' want those anyway.
As this changes the cmake target(s) we link against, this will also prevent issues with thrust 1 vs 2 cmake suggested above, by always requiring CCCL.