Delete cccl_adaptors.hpp and use raw CCCL resource_ref types#2325
Draft
bdice wants to merge 4 commits intorapidsai:stagingfrom
Draft
Delete cccl_adaptors.hpp and use raw CCCL resource_ref types#2325bdice wants to merge 4 commits intorapidsai:stagingfrom
bdice wants to merge 4 commits intorapidsai:stagingfrom
Conversation
|
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. |
This was referenced Mar 20, 2026
rapids-bot bot
pushed a commit
that referenced
this pull request
Mar 23, 2026
…#2328) Replace the hand-rolled friend `get_property` templates in `cccl_resource_ref` and `cccl_async_resource_ref` with inheritance from `cuda::forward_property`. This delegates property forwarding to CCCL's own machinery, which correctly handles `dynamic_accessibility_property` ([NVIDIA/cccl#7727](NVIDIA/cccl#7727)) and any future properties without ambiguity. Each wrapper now exposes `upstream_resource()` returning the inner `ResourceType`, as required by `forward_property` for stateful properties. Tests add minimal `forward_property` adaptors using RMM resource refs as upstream, exercising the exact scenario that causes the ambiguity. Note: this is a temporary solution for the `main` branch -- resolving #2323 / #2325 will remove this code on the `staging` branch while I continue working on CCCL MR migrations. Closes #2322. Authors: - Bradley Dice (https://github.com/bdice) Approvers: - Rong Ou (https://github.com/rongou) URL: #2328
bdice
added
breaking
bdice
force-pushed
the
delete-cccl-adaptors
branch
from
8a3dfa6 to
0f59bf7
Compare
…onstraint cycle Replace device_async_resource_ref constructor parameters with cuda::mr::any_resource<device_accessible> across all adaptor impl classes. Add template constructors (constrained with !is_same_v<decay_t<T>, AdaptorType>) to public adaptor headers for single-arg-capable constructors, breaking the recursive is_constructible cycle that CCCL #8037 causes. Multi-arg constructors that cannot be confused with copy/move use plain any_resource params with out-of-line definitions. Update Python/Cython bindings with any_device_resource type alias and _to_any_resource() wrapper at all call sites to work around Cython's inability to call C++ template constructors directly.
…urce_adaptor to store any_resource members Replace device_async_resource_ref members with cuda::mr::any_resource<device_accessible> in polymorphic_allocator, thrust_allocator, and device_check_resource_adaptor. This eliminates the CCCL #8037 recursive constraint cycle for these classes. polymorphic_allocator uses a template constructor with SFINAE (is_polymorphic_allocator_v) because it is a class template with a 1-arg constructor, matching the pattern used by the adaptor classes.
Replace RMM's wrapper types (cccl_resource_ref, cccl_async_resource_ref)
with direct aliases to CCCL's resource_ref and synchronous_resource_ref.
This eliminates the 469-line adaptor layer that was originally needed to
work around shared_resource type-erasure issues.
The wrapper was no longer needed once the CCCL #8037 recursive constraint
cycle was broken via template SFINAE constructors (previous commit).
Additional changes required for compilation without the wrapper:
- per_device_resource: static_cast<any_device_resource>(ref) replaced
with any_device_resource{ref} (wrapper had operator any_resource)
- cuda_async_memory_resource, cuda_async_managed_memory_resource,
sam_headroom_memory_resource: copy/move changed from = delete to
= default (CCCL resource_ref requires copyability; shared_resource
base already provides correct reference-counted semantics)
- device_check_resource_adaptor (test): template SFINAE constructor
to break the same CCCL #8037 cycle
…hmark The any_resource internals use __host__ __device__ functions that call shared_resource copy/move constructors which are __host__ only. This is safe because the benchmark factory functions are only called from host code.
bdice
force-pushed
the
delete-cccl-adaptors
branch
from
0f59bf7 to
423eeac
Compare
Collaborator
Author
|
I'm going to break this up into smaller PRs. I'm not 100% convinced all the changes are still necessary. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
polymorphic_allocator,thrust_allocator, anddevice_check_resource_adaptorto storeany_resourcemembers instead of non-owningresource_refcccl_adaptors.hppand replace RMM'sresource_reftype aliases with direct CCCL typesmulti_stream_allocations_bench.cuCloses #2323
Part of #2011