You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working out a solution to the later half of my issue in #1571 , it occurred to me that a generic sub-view like class would be the best way to deal with the pointer issue I was running into earlier. I was curious if this might be something that the RAJA team might be interested in supporting as I'm sure several people might also find it useful to have a subview/slice/window of a larger view.
I've included my initial proof-of-concept of such a subview / window class below that we're using in our library. The below also has the added functionality that it can act like a "rolling" window as we had a need for such a feature also arose in this same library for a couple special cases.
I do realize that making this making this sorta class work for how generic RAJA views are might not be the simplest thing, and @gberg617 has already brought up some things I hadn't considered. Since at least in my use case, we can make a number of assumptions with the below class such as only ever taking slices along the slowest index and only wanting a rolling window on the 2nd slowest index which greatly simplifies things.
// We really don't care what View class we're using as the sub-view just wraps it up// and then allows us to take a slice/window of the original view// Should probably work out some form of SFINAE to ensure T that we've templated on// is an actual View class that we can use...template<classT>
classsubview {
public:// Delete the default constructor as that wouldn't be a valid object
__host__ __device__
subview() = delete;
// where we don't want any offset within the subview itself
__host__ __device__
subview(constint index, T& view) : m_view(view), m_index(index), m_offset(0) {};
// sometimes you might want to have an initial offset in your subview when constructing// your subview in which everything appears as 0 afterwards
__host__ __device__
subview(constint index, constsize_t offset, T& view) : m_view(view), m_index(index), m_offset(offset) {};
~subview() = default;
// Could probably add default copy constructors as well here if need be...// Let the compiler figure out the correct return type here as the one from// RAJA at least for regular Views is non-trivial// make the assumption here that we're using row-major memory order for views// so m_index is in the location of the slowest moving index as this is the default// for RAJA...template <typename... Args>
__host__ __device__
inlineconstexprauto&
operator()(Args... args) const
{
// The use of m_offset here provides us the equivalent of a rolling// subview/window if our application needs itreturnm_view(m_index, m_offset + args...);
}
// If we need to have like a rolling subview/window type class then// we'd need some way to update the offset in our slowest moving index// in the subview (so not m_view's slowest index)
__host__ __device__
inlinevoidset_offset(constint offset) const
{
// Might want an assert in here for debugs to make sure that this is within// the bounds of what m_view expects is a valid offset
m_offset = offset;
}
private:// Internally we shouldn't be modifying the view itself so let's make it constantconst T& m_view;
constint m_index = 0;
mutablesize_t m_offset = 0;
};
The text was updated successfully, but these errors were encountered:
While working out a solution to the later half of my issue in #1571 , it occurred to me that a generic sub-view like class would be the best way to deal with the pointer issue I was running into earlier. I was curious if this might be something that the RAJA team might be interested in supporting as I'm sure several people might also find it useful to have a subview/slice/window of a larger view.
I've included my initial proof-of-concept of such a subview / window class below that we're using in our library. The below also has the added functionality that it can act like a "rolling" window as we had a need for such a feature also arose in this same library for a couple special cases.
I do realize that making this making this sorta class work for how generic RAJA views are might not be the simplest thing, and @gberg617 has already brought up some things I hadn't considered. Since at least in my use case, we can make a number of assumptions with the below class such as only ever taking slices along the slowest index and only wanting a rolling window on the 2nd slowest index which greatly simplifies things.
The text was updated successfully, but these errors were encountered: