-
Notifications
You must be signed in to change notification settings - Fork 914
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
Use pre-built nvcomp 2.3 binaries by default #10851
Use pre-built nvcomp 2.3 binaries by default #10851
Conversation
When building cudf on x86_64 hardware we can enable the new pre-built nvcomp 2.3 binaries to leverage new compression codec support.
Waiting on rapidsai/rapids-cmake#190 |
@robertmaynard do you want to pull the changes from #10837 into this PR? |
Yeah I will do so |
Codecov Report
@@ Coverage Diff @@
## branch-22.06 #10851 +/- ##
================================================
+ Coverage 86.30% 86.32% +0.02%
================================================
Files 144 144
Lines 22665 22668 +3
================================================
+ Hits 19560 19569 +9
+ Misses 3105 3099 -6
Continue to review full report at Codecov.
|
2c4bc16
to
c1e5275
Compare
build.sh
Outdated
@@ -144,6 +146,7 @@ function buildLibCudfJniInDocker { | |||
-DCMAKE_CUDA_ARCHITECTURES=${CUDF_CMAKE_CUDA_ARCHITECTURES} \ | |||
-DCMAKE_INSTALL_PREFIX=/usr/local/rapids \ | |||
-DUSE_NVTX=ON \ | |||
-DCMAKE_USE_PROPRIETARY_NVCOMP=ON \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find it a bit disconcerting that all of the flags used for the JNI build do not respect the script's CLI. That seems like it's just waiting to bite some unsuspecting user of build.sh
eventually. It looks like this isn't a new problem though since it affects all of the flags used in the JNI build, though, so we don't need to block this PR over this. It's probably worth factoring this build logic into a separate script thought since AFAICT it completely ignores all of the logic and variables in this build.sh script.
@vyasr I was able to build spark-rapids-jni. |
To answer my own question, the version we download is specified here: https://github.com/rapidsai/rapids-cmake/blob/branch-22.06/rapids-cmake/cpm/versions.json |
Yep, sorry for the slow response. Versions for packages that we need to be standardized across all of rapids are stored in the rapids-cmake file that you pointed to. The rapids-cmake function is being called in the get_nvcomp.cmake file in this repository. Regarding the nvcomp update, should we hold off on this PR until there is an nvcomp version with the necessary bug fix? |
Closes #10681 |
Just to give an update for those tracking this PR, we're holding off on merge while we wait to resolve issues with nvcomp 2.3.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@robertmaynard based on our meeting I think we are good to move forward with this, correct? I'll approve and let you merge when ready.
This PR addresses #10862, but does not completely remove `PER_THREAD_DEFAULT_STREAM`. I just adds the new define `CUDF_USE_PER_THREAD_DEFAULT_STREAM` and adds a deprecation warning for `PER_THREAD_DEFAULT_STREAM`. This PR also addresses #10864, but only changes the default parameter for `read_avro` and `read_parquet` to `cudf::default_stream_value`, which is defined as `rmm::cuda_stream_per_thread` when `CUDF_USE_PER_THREAD_DEFAULT_STREAM` is defined. These cover the current interfaces to nvcomp. The goal for this PR is to ensure that we pass `rmm::cuda_stream_per_thread` to the nvcomp apis when `CUDF_USE_PER_THREAD_DEFAULT_STREAM` is defined. This is needed for nvcomp-2.3, which is provided as dynamic libraries where we cannot recompile with PTDS enabled. nvcomp-2.3 is being enabled in #10851. I have not marked this PR as closing the above issues, because we will need to follow up in a future PR to remove `PER_THREAD_DEFAULT_STREAM` and in another to replace all of the rest of the cuDF API call sites to use the new `cudf::default_stream_value`. i am putting this up as a draft PR because I have not tested with nvcomp-2.3 yet. Authors: - Jim Brennan (https://github.com/jbrennan333) Approvers: - https://github.com/nvdbaranec - AJ Schmidt (https://github.com/ajschmidt8) - Jason Lowe (https://github.com/jlowe) - Vukasin Milovanovic (https://github.com/vuule) - Jake Hemstad (https://github.com/jrhemstad) - Robert Maynard (https://github.com/robertmaynard) URL: #10877
@gpucibot merge |
When building cudf on x86_64 hardware we can enable the new pre-built nvcomp 2.3 binaries to leverage new compression codec support.
Closes #10681
Closes #10837