-
Notifications
You must be signed in to change notification settings - Fork 915
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
CMAKE_CUDA_ARCHITECTURES doesn't change when build-system invokes cmake #7579
CMAKE_CUDA_ARCHITECTURES doesn't change when build-system invokes cmake #7579
Conversation
Consider the following: ``` cmake -DCMAKE_CUDA_ARCHITECTURES="" . #build for detected touch <cudf_dir>/cpp/CMakeLists.txt ninja #should be build for detected cmake -DCMAKE_CUDA_ARCHITECTURES= . #build for all touch <cudf_dir>/cpp/CMakeLists.txt ninja #should be build for all cmake -DCMAKE_CUDA_ARCHITECTURES="" . #build for detected touch <cudf_dir>/cpp/CMakeLists.txt ninja #should be build for detected ``` Before these changes the invocations of `ninja` would always go back to building for all when ever `ninja` was invoked. The issue is that once a CMake cache variable exists it can't be removed via `-DCMAKE_CUDA_ARCHITECTURES=` and therefore becomes sticky. To resolve the issue you can now pass `-DCMAKE_CUDA_ARCHITECTURES=ALL` to consistently get all archs, and now the build-system should not change what CUDA archs you are building for.
@gpucibot merge |
rerun tests |
Anything I can do to resolve that issue from CI? |
Will be fixed in #7580 |
rerun tests |
Codecov Report
@@ Coverage Diff @@
## branch-0.19 #7579 +/- ##
===============================================
+ Coverage 81.86% 81.99% +0.12%
===============================================
Files 101 101
Lines 16884 16989 +105
===============================================
+ Hits 13822 13930 +108
+ Misses 3062 3059 -3
Continue to review full report at Codecov.
|
Fixes regression from #7579 in auto-detecting GPU architectures when `-DCMAKE_CUDA_ARCHITECTURES=` is passed on the CLI. Now that the cached `CMAKE_CUDA_ARCHITECTURES` isn't unset before calling `enable_language(CUDA)`, this call throws an error and configuration fails. This change ensures we call `enable_language(CUDA)` after any potential rewrites of `CMAKE_CUDA_ARCHITECTURES`. This PR also aligns with RMM's `EvalGPUArchs.cmake` logic and prints `SUPPORTED_CUDA_ARCHITECTURES` instead of `"ALL"` in the case the current machine is a CPU-only node. Related: rapidsai/rmm#727 Authors: - Paul Taylor (@trxcllnt) - Robert Maynard (@robertmaynard) Approvers: - Keith Kraus (@kkraus14) URL: #7593
…ke (rapidsai#7579) Consider the following: ``` cmake -DCMAKE_CUDA_ARCHITECTURES="" . #build for detected touch <cudf_dir>/cpp/CMakeLists.txt ninja #should be build for detected cmake -DCMAKE_CUDA_ARCHITECTURES= . #build for all touch <cudf_dir>/cpp/CMakeLists.txt ninja #should be build for all cmake -DCMAKE_CUDA_ARCHITECTURES="" . #build for detected touch <cudf_dir>/cpp/CMakeLists.txt ninja #should be build for detected ``` Before these changes the invocations of `ninja` would always go back to building for all when ever `ninja` was invoked. The issue is that once a CMake cache variable exists it can't be removed via `-DCMAKE_CUDA_ARCHITECTURES=` and therefore becomes sticky. To resolve the issue you can now pass `-DCMAKE_CUDA_ARCHITECTURES=ALL` to consistently get all archs, and now the build-system should not change what CUDA archs you are building for. Authors: - Robert Maynard (@robertmaynard) Approvers: - Keith Kraus (@kkraus14) URL: rapidsai#7579
Consider the following:
Before these changes the invocations of
ninja
would alwaysgo back to building for all when ever
ninja
was invoked. The issueis that once a CMake cache variable exists it can't be removed
via
-DCMAKE_CUDA_ARCHITECTURES=
and therefore becomes sticky.To resolve the issue you can now pass
-DCMAKE_CUDA_ARCHITECTURES=ALL
to consistently get all archs, and now the build-system should not
change what CUDA archs you are building for.