Customization point for iterators to be passed directly #1939
masterleinad
started this conversation in
Ideas
Replies: 1 comment 11 replies
-
For |
Beta Was this translation helpful? Give feedback.
11 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
#855 provides an example were users want to provide their own iterators that reference data on the device. Currently, this causes segfaults since
oneDPL
is creating a CPU-side copy of the respective elements before launching the algorithm.This problem also appeared in
Kokkos
, see kokkos/kokkos#7502.Kokkos
defines aRandomAccessIterator
class that references aKokkos::View
that manges the respective data and has similar functionality tomdspan
(the latter was inspired by the former). This means that the access pattern can be anything although in most cases consecutive elements are a constant stride apart. This means that simply passing raw pointers tooneDPL
doesn't represent the iterator space correctly andoneDPL
algorithms can't be used (without copying data to a continuous buffer on the host or device).Whether to create CPU-side buffers is controlled by
oneapi::dpl::__internal::is_passed_directly
which basically looks for anis_passed_directly
alias in the iterator class.This works but pollutes user-defined classes (and the alias name doesn't indicate that the alias is used in
oneDPL
).#861 provides a solution that provides a wrapper class called
direct_iterator
so that forwards all iterator calls the wrapped class. A different solution is opposed in #861 (comment) by introducing a customization point in the publiconedpl
namespace such asonedpl::is_passed_directly
similar tosycl::is_device_copyable
.Beta Was this translation helpful? Give feedback.
All reactions