-
Notifications
You must be signed in to change notification settings - Fork 407
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
Add variant of subview that lets users add traits #134
Comments
Likely do-able simply as: auto x = subview< Traits >( ... ); |
The refactored View will allow compatible subview construction as |
When you say "likely do-able," does that mean it works now, or that it's easy to make that work? |
That means we can add that without too much trouble. |
Putting this feature in the experimental view.
The constructor for subview performs a static_assert on whether the subview type, primary view type, and subview arguments are compatible. |
Ok that should be good enough for now. Btw your naming was a bit unfortunate took me a bit to get what you was saying better: View<...> a_view(...allocation_arguments...);
View<...> a_sub_view(a_view, ... subview_arguments...); Do we still want auto a_sub_view = subview<Traits>(a_view, ...subview_arguments...); In the first scheme I need to know what the data_type, layout and memory space are, in the second I don't. |
I've already hacked up a bit of the "add traits" functionality in Tpetra, for ensuring that I get unmanaged Views, no matter what type of input View comes in. It would be nice if Kokkos provided that :-) |
Nearly trivial addition to experimental view:
Does a static_assert that MemoryTraits are really memory traits. |
… that have different traits than the source view. View<...> a( ...allocation... ); View<...> b( a , ...subview_arguments... ); satisfies feature request issue #134
…returns a subview with the specified memory traits. Feature request issue #134
Don't close until its in master. |
Pushed to master |
Add Kokkos::subview variant that lets users add traits (e.g., Atomic, MemoryUnmanaged, RandomRead) to the resulting type. This is particularly useful for creating an unmanaged subview of a managed View, since it would avoid the intermediate step of assigning from a managed to an unmanaged View (before taking the subview). It might look something like this:
The advantage is that users would not need to know the exact return type (which is tricky given different layouts and slices!), yet could still add traits to it.
The text was updated successfully, but these errors were encountered: