Re-Render to support CUDA 11.8

[DavidMChan]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[DavidMChan]

This should (probably) resolve #9, however needs review.

[jakirkham]

Thanks David! 🙏

Looks pretty good

Do we want to update the GPU arches here?

tsnecuda-feedstock/recipe/build.sh

Lines 11 to 28 in 58be9c9

	# the following are all the x86-relevant gpu arches; for building aarch64-packages, add: 53, 62, 72
	ARCHES=(52 60 61 70)
	# cuda 11.0 deprecates arches 35, 50
	DEPRECATED_IN_11=(35 50)
	if [ $(version2int $cuda_compiler_version) -ge $(version2int "11.1") ]; then
	# Ampere support for GeForce 30 (sm_86) needs cuda >= 11.1
	LATEST_ARCH=86
	# ARCHES does not contain LATEST_ARCH; see usage below
	ARCHES=( "${ARCHES[@]}" 75 80 )
	elif [ $(version2int $cuda_compiler_version) -ge $(version2int "11.0") ]; then
	# Ampere support for A100 (sm_80) needs cuda >= 11.0
	LATEST_ARCH=80
	ARCHES=( "${ARCHES[@]}" 75 )
	elif [ $(version2int $cuda_compiler_version) -ge $(version2int "10.0") ]; then
	# Turing support (sm_75) needs cuda >= 10.0
	LATEST_ARCH=75
	ARCHES=( "${DEPRECATED_IN_11[@]}" "${ARCHES[@]}" )
	fi

Might be worth dropping the old CUDA versions (pre-11.2) and adding the new ones (11.8 and 12.0)

[DavidMChan]

Ah, that's a good point - I didn't see this file. Let me take a look.

[jakirkham]

If it is helpful, PyTorch has analogous logic that could be adapted here

[jakirkham]

Another option might be to just move this to script_env in meta.yaml and drop the bash logic. We made similar changes in nvidia-apex, which could be a good reference point

[DavidMChan]

So I was looking a bit closer at this today, and from what I can tell, we just ignore this code completely in our upstream CMakeLists (https://github.com/CannyLab/tsne-cuda/blob/2dad49713ba451c0953b646a85ac2567b5d1070e/CMakeLists.txt#L61), since we use the variable CUDA_ARCH, and set it based on the detected CUDAToolkit version. I removed this logic completely, and it seems to still work as expected, but I don't know for sure if these variables have other impacts beyond our upstream package.

@jakirkham - thoughts on how to handle this? I think the best thing is just to remove the dead code and handle it upstream, but I'm open to changing the way the upstream works if that's more transparent to conda-forge

[jakirkham]

Sounds reasonable to me. Thanks for investigating David! 🙏

Mainly conda-forge packages set it when upstream doesn't have a constraint (or not one we can easily handle on CI here). So packages sometimes need to trim the matrix a bit to keep things manageable. Though no need to do that here if the defaults from upstream cover a good range of architectures and build ok here

[jakirkham]

@conda-forge-admin , please re-render

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you but ran into some issues. Please check the output logs of the latest webservices GitHub actions workflow run for errors. You can also ping conda-forge/core for further assistance or you can try rerendeing locally.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/tsnecuda-feedstock/actions/runs/8917978585.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

[jakirkham]

@conda-forge-admin , please re-render

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jakirkham]

@conda-forge-admin , please re-render

[h-vetinari]

@DavidMChan, I'm very sorry that I didn't see this PR! 😑

I rebased it into #12 (without some of the churn-y rerender commits), but I'd very much like to keep you on as a maintainer!

[DavidMChan]

Thanks! No worries! Hopefully we can get #12 merged -- I've been pretty behind on issues on the source repo too, so it's all good!