Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEA] Support all CTK-supported SM arches in cuda_init_architectures #104

Closed
alliepiper opened this issue Oct 19, 2021 · 1 comment
Closed
Labels
feature request New feature or request

Comments

@alliepiper
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Thrust supports all architectures supported by CTK, including deprecated ones. This means we currently need to build against SM35+ in our benchmarking library.

However, rapids_cuda_init_architectures only adds architectures supported by RAPIDS (sm60+) when CMAKE_CUDA_ARCHITECTURES=ALL.

Describe the solution you'd like

Ideally, these special values would be something like:

  • ALL: non deprecated arches supported by CTK (e.g. sm53+)
  • ALL_LEGACY: all arches supported by CTK, including deprecated (e.g. sm35+)
  • RAPIDS: all arches supported by RAPIDS (e.g. sm60+)

Since the current convention around ALL is already in use by rapids-cmake users, maybe the following values would be more agreeable and less disruptive:

  • CTK: non deprecated arches supported by CTK (e.g. sm53+)
  • CTK_LEGACY: all arches supported by CTK, including deprecated (e.g. sm35+)
  • ALL / RAPIDS: all arches supported by RAPIDS (e.g. sm60+)

Also -- I'm not sure if NATIVE will add <sm60 if such a card is present. If not, adding NATIVE_CTK + NATIVE_CTK_LEGACY (or similar) would be useful for us.

Describe alternatives you've considered

We can still just list all arches explicitly, so this is a low-priority issue with an easy workaround. Most users will want NATIVE anyway.

@alliepiper alliepiper added ? - Needs Triage Need team to review and classify feature request New feature or request labels Oct 19, 2021
@robertmaynard robertmaynard removed the ? - Needs Triage Need team to review and classify label Oct 20, 2021
@robertmaynard
Copy link
Contributor

Closing this issue as #314 better represents what rapids-cmake will do.

If you need to build with against all support archs, using the new CMAKE_CUDA_ARCHITECTURES=all/all-major is the best approach.

@robertmaynard robertmaynard moved this to Done in rapids-cmake Dec 1, 2022
rapids-bot bot pushed a commit that referenced this issue Jan 4, 2023
CMake 3.23+ now offers support for `all` and `all-major` as special keywords to `CMAKE_CUDA_ARCHITECTURES`. This means that rapids-cmake overload on `ALL` now creates confusion and breaks expectations ( trxcllnt/rapids-compose#84 https://gitlab.kitware.com/cmake/cmake/-/issues/23739, #104 ) 

This PR introduces the new magic keyword of `RAPIDS` which behaves the same as `ALL`, and will become the new apporved approach for projects that want to build for RAPIDS supported platforms.

Fixes #314


More details on the plans of deprecation for `ALL` can be found at: #318

Authors:
  - Robert Maynard (https://github.com/robertmaynard)

Approvers:
  - Bradley Dice (https://github.com/bdice)

URL: #327
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
Archived in project
Development

No branches or pull requests

2 participants