[FEA]: Make Thrust types have a consistent ABI between host and device code #1262
Assignees
Labels
Comments
|
@robertmaynard @bdice could one or both of you help us with finalizing the list of types that RAPIDS depends on this functionality? |
jrhemstad
changed the title
miscco
added a commit
to miscco/cccl
that referenced
this issue
Feb 8, 2024
We have issues with the internal versioning of thrust types that may end up in a public API. As we utilize cuda architectures for an internal namespace etc those types turn out to be different between host and device TUs. Therefore, put types inte a plain unversioned namespace Addresses NVIDIA#1262
miscco
added a commit
to miscco/cccl
that referenced
this issue
Feb 8, 2024
We have issues with the internal versioning of thrust types that may end up in a public API. As we utilize cuda architectures for an internal namespace etc those types turn out to be different between host and device TUs. Therefore, put types inte a plain unversioned namespace Addresses NVIDIA#1262
miscco
added a commit
to miscco/cccl
that referenced
this issue
Feb 8, 2024
We have issues with the internal versioning of thrust types that may end up in a public API. As we utilize cuda architectures for an internal namespace etc those types turn out to be different between host and device TUs. Therefore, put types inte a plain unversioned namespace Addresses NVIDIA#1262
|
We decided that this will not be feasible rather than that we want to work with upstream to not use thrust types in API interfaces when not necessary |
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is this a duplicate?
Area
Thrust
Is your feature request related to a problem? Please describe.
Thrust uses an inline namespace that embeds the CUDA architectures to avoid symbol collision issues. However, this causes problems where you can't pass Thrust types compiled in a host-only TU with a device TU.
Describe the solution you'd like
Remove types like
optional,pair, etc. from the inline namespace.Tasks
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: