CUCO_CUDA_MINIMUM_ARCH not correctly expanded when building with CUDA 11.4.0-11.4.4.

[sleeepyjack]

  There seems too be an issue when building with CUDA 11.4.0-11.4.4.

Here is a reproducer: https://godbolt.org/z/YsbTM8GPd

Originally posted by @sleeepyjack in #244 (comment)

[sleeepyjack]

I also noticed, that since we switched to NV_IF_TARGET, we somehow lost support for CUDA <11.4.0 in godbolt: https://godbolt.org/z/Kj3zW56Eh
I this because the build is picking up the libcu++ version that is included in the CTK, which is too old?

[PointKernel]

<nv/target> was introduced in libcu++ 1.5.0 (CTK 11.4) so it doesn't work with earlier CTK versions. 😞

The effort to support pre CUDA-11.5 seems unnecessary to me. We could update the requirements to nvcc 11.5.0.

cc @jrhemstad

[sleeepyjack]

<nv/target> was introduced in libcu++ 1.5.0 (CTK 11.4) so it doesn't work with earlier CTK versions. 😞

The effort to support pre CUDA-11.5 seems unnecessary to me. We could update the requirements to nvcc 11.5.0.

The problem is not only the absence of <nv/target> (we only use it to conveniently retrieve the first arg of a macro list) but additionally said list of GPU architectures (__CUDA_ARCH_LIST__) is only available from CUDA 11.5 onwards.

So yes, I agree, it would be best to drop the support for CUDA <11.5 IMO.

[jrhemstad]

What do we use __CUDA_ARCH_LIST__ for in cuco?

[jrhemstad]

Also, there is no reason to tie CTK support version to libcu++ version. You can get a newer version of libcu++ from GitHub than what is in your CTK. cuco's cmake config will even do it for you via CPM.

[sleeepyjack]

What do we use __CUDA_ARCH_LIST__ for in cuco?

since this list is sorted, we can use it to find the minimum arch by extracting the first element. We currently use this to determine if we are running on Volta+ architectures only.

cuCollections/include/cuco/detail/__config

Line 22 in 2a194c9

#define CUCO_CUDA_MINIMUM_ARCH _NV_FIRST_ARG(__CUDA_ARCH_LIST__)

[PointKernel]

there is no reason to tie CTK support version to libcu++ version.

Totally agreed.

Sorry, I wasn't clear. What I wanted to bring up is the fact that users may not know the relationship/dependency between CTK and libcu++. So to solve issues like #244, changing the compiler to nvcc-11.5+ is a much simpler solution compared to asking them to install a newer version of libcu++ on their own.

[sleeepyjack]

But why does the missing <nv/target> problem show up on godbolt? Is it just including the headers instead of configuring the project using cmake, i.e. pulling in the dependencies?

[PointKernel]

The <nv/target> header doesn't exist in libcu++ 1.4.0 (or CTK 11.3) or earlier

[sleeepyjack]

Yeah but if cuco is configured using cmake it will pull in whatever libcu++ version we have specified which should be newer than whatever the CTK provides. If however godbolt only includes the headers, then it will fall back to the CTKs libcu++ version.

[jrhemstad]

If however godbolt only includes the headers, then it will fall back to the CTKs libcu++ version.

Hm, yeah, that's actually a good point. We'd need to update how cuco is added to CE to get it to pull in the appropriate libcu++ dependency as well. Looking at the docs it looks like there's a way to define the library such that it will run the cmake build (which is what we'd want to have CPM fetch the version of libcu++ that we want).

We'd want to modify that here: https://github.com/compiler-explorer/infra/blob/269d4fd0f85aacb2a2ec86fb4355989130f5d7c6/bin/yaml/libraries.yaml#L1724