refactor: replace rmm::device_scalar with cudf::detail::device_scalar - #23618
refactor: replace rmm::device_scalar with cudf::detail::device_scalar#23618vyasr wants to merge 3 commits into
Conversation
Introduce a self-contained cudf::detail::device_scalar<T> wrapper (size-1 rmm::device_uvector storage) and migrate all libcudf source, tests, and libcudf_streaming to use it. Updates the scalar hierarchy ctor signatures from rmm::device_scalar<T> to cudf::detail::device_scalar<T> (public API change), refreshes DEVELOPER_GUIDE.md guidance. This completes plan drop-rmm-device-scalar.md. A follow-up change removes the final rmm::device_scalar usage in compute_single_pass_aggs.cuh.
Replace the exemption rmm::device_scalar<cuda::std::atomic_flag> in compute_single_pass_aggs.cuh with rmm::device_uvector<cuda::std::atomic_flag> of size 1 — semantically identical (device_scalar is a size-1 device_uvector under the hood) but eliminates the last direct rmm::device_scalar reference from libcudf source. atomic_flag cannot use cudf::detail::device_scalar because it is not trivially copyable, but device_uvector has no such requirement. Completes plan drop-final-rmm-device-scalar-usage.md.
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
| [[nodiscard]] T const* data() const noexcept { return _storage.data(); } | ||
|
|
||
| private: | ||
| rmm::device_uvector<T> _storage; |
There was a problem hiding this comment.
Should we just go straight to cuda::buffer here?
There was a problem hiding this comment.
I chose not to, I'd prefer to do all the cuda::buffer switches concurrently so that reviewers can see the type in action in multiple places at once for comparison.
vyasr
added
improvement
| * @param mr Device memory resource to use for device memory allocation. | ||
| */ | ||
| fixed_width_scalar(rmm::device_scalar<T>&& data, | ||
| fixed_width_scalar(cudf::detail::device_scalar<T>&& data, |
There was a problem hiding this comment.
This certainly gives me some pause. We have essentially turned this constructor from public to internal since it requires an internal class to call it.
This has come up before with the same concerns.
Perhaps new constructors should be added for the detail parameter and keep the rmm::device_scalar ones in place?
| Use this for scalar input/outputs into device kernels, e.g., reduction results, null count, etc. | ||
|
|
||
| Key properties: | ||
| - Owns `rmm::device_uvector<T> _storage{1, stream, mr}`. |
There was a problem hiding this comment.
Is the device_uvector important information in the developer guide?
I saw Bradley's comment about cuda::buffer and it seems this would need to be kept insync with internal/private data members of the class.
|
|
||
| // Flag indicating whether a global memory aggregation fallback is required or not. | ||
| rmm::device_scalar<cuda::std::atomic_flag> needs_global_memory_fallback(stream); | ||
| rmm::device_uvector<cuda::std::atomic_flag> needs_global_memory_fallback(1, stream); |
There was a problem hiding this comment.
Probably worth adding or just moving the Cannot use device_scalar::value ... comment here. Using a device vector of size 1 is not an obvious solution because of atomic_flag.
|
Yikes I'm sorry I only meant to update the branch and not take this out of draft. Well, thank you @davidwendt @PointKernel @bdice for the reviews! I will try to address them ASAP. I was trying to figure out what to do about the public APIs before opening this up for review anyway, so David's question is apropos. |
4 participants
Description
Replaces libcudf's direct
rmm::device_scalarusage withcudf::detail::device_scalar, which now owns size-1rmm::device_uvectorstorage directly. Also removes the finalrmm::device_scalar<cuda::std::atomic_flag>use in groupby hash aggregation by using a size-1rmm::device_uvectorinstead. The developer guide is updated accordingly.Checklist