-
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
Fix alignment of compressed blocks in ORC writer #12077
Fix alignment of compressed blocks in ORC writer #12077
Conversation
…bug-nvcomp-deflate-align
…bug-nvcomp-deflate-align
Codecov ReportBase: 87.47% // Head: 88.08% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## branch-22.12 #12077 +/- ##
================================================
+ Coverage 87.47% 88.08% +0.60%
================================================
Files 133 135 +2
Lines 21826 22100 +274
================================================
+ Hits 19093 19466 +373
+ Misses 2733 2634 -99
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
util::round_up_unsafe<size_t>(max_compressed_block_size, compressed_block_align); | ||
auto const padded_block_header_size = | ||
util::round_up_unsafe<size_t>(block_header_size, uncomp_block_align); | ||
util::round_up_unsafe<size_t>(block_header_size, compressed_block_align); |
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.
Actual fix for the alignment. Everything else is to safely re-enable DEFLATE compression.
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.
Looks good! I just had a few minor comments.
…bug-nvcomp-deflate-align
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.
+1 looks good to me
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'm glad we have tests now. Do we actually cover a good portion of the version/hardware cases in our testing (manual or CI)?
return NVCOMP_HAS_ZSTD_COMP and detail::nvcomp_integration::is_stable_enabled(); | ||
default: return false; | ||
case compression_type::DEFLATE: { | ||
if (not NVCOMP_HAS_DEFLATE( |
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 suppose this expands to a valid runtime expression as well as being useful at compile time in #if
macros? Not super familiar with using macros like this.
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.
It is simply a compile time text substitution, so this one will translate to if (not (MAJOR > 2 or (MAJOR == 2 and MINOR >= 5)))
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.
Not super familiar with using macros like this.
Yeah, this is tech from the dark ages, thankfully not commonly used any more. I unfortunately could not avoid it here :(
I think you have the right idea, this is pretty much a type-unsafe constexpr function that can be used in #if
conditions. By the means of text substitution, as Mike said :D
cpp/src/io/comp/nvcomp_adapter.hpp
Outdated
|
||
feature_status_parameters(); | ||
feature_status_parameters( | ||
int major, int minor, int patch, bool all_enabled, bool stable_enabled, int cc) |
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.
Compute capabilities are not really integral, there are lots of values like 8.6
or 6.1
. Does this get some kind of normalized integral value like 86
? How does this interact with params.compute_capability == 6
?
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.
Looks like my naming is bad here.
This is just the major capability number.
cudaDeviceGetAttribute(&compute_capability, cudaDevAttrComputeCapabilityMajor, device))
returns an int so this should be fine.
I'll fix the name to avoid confusion.
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.
Renamed to reflect that this is the major
component of compute capability.
I don't know about HW, but we definitely only cover a single nvCOMP version. |
; branch 'branch-22.12' of https://github.com/rapidsai/cudf into bug-nvcomp-deflate-align
rerun tests |
@gpucibot merge |
Description
Closes #11812
Fixed alignment of compressed blocks in ORC writer - impacted ZLIB compression.
Re-enabled nvCOMP DEFLATE compression in ORC - nvCOMP 2.5+ only.
Refactored the nvCOMP feature status(enabled/disabled in cuDF) checks to include reason why features are not enabled (if not enabled).
Refactored call sites to return the detailed error message if an operation fails because of nvCOMP integration config.
Refactored nvCOMP adapter macros to allow mocking of the parameters that determine if an nvCOMP feature is enabled (env var, GPU compute capability, nvCOMP version).
Added tests to verify the logic of the newly refactored feature status checks (allowed by the mocking above).
Fix a Parquet test that was calling ORC reader/writer 😬
Checklist