Skip to content

[SYCL] Add structure to pass references to ranges #19805

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

Draft
wants to merge 11 commits into
base: sycl
Choose a base branch
from

Conversation

Alexandr-Konovalov
Copy link
Contributor

This allows to have single entry point for all dimentions and keep reference to user-provided range data, not copy them.

This allows to have single entry point for all dimentions and keep
reference to user-provided range data, not copy them.

// The structure to keep references to ranges and dimension unified for
// all dimensions.
class RangesRefT {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just thinking out load, would it be better to call this class ranges_ref_view? Since this class is just a "view" over the user-provided range and doesn't own the lifetime of the underlying range object. Similar to how string_view or ranges::ref_view (https://www.en.cppreference.com/w/cpp/ranges/ref_view.html) works.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, done.

@Alexandr-Konovalov
Copy link
Contributor Author

Issue probably related to the test fail: Reduction/reduction_internal_nd_range_1dim.cpp sporadically fails in pre-commit BMG&L0 #19767


// The structure to keep dimension and references to ranges unified for
// all dimensions.
class ranges_ref_view {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure that it is the best name. We have sycl::range and someone might assume that ranges_ref_view is a view to the sycl::range. Also it is not lear what _ref_ means in the name. Why not just nd_range_view?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

View has strong connotation to views from C++20, that may be or may be not good.

Alternatively, it can be nd_range_ref. I don't know.

Also it is not lear what ref means in the name.

That's for "reference", I hope.


#include <gtest/gtest.h>

TEST(RangesRefUsage, RangesRefUsage) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The testing logic for 1,2 and 3 dimensions ranges_ref_view is the same. Would it be possible to abstract out the testing logic in a function, templated over the dimension parameter?
For example:

template <int dims>
void TestNDRangesRefView(sycl::ranges<dims> global, sycl::ranges<dims> local, sycl::id<dims> offset) {
sycl::nd_range<dims> nd_range{global, local, offset};
  {
    sycl::detail::ranges_ref_view r{nd_range};
     ASSERT_EQ(r.Dims, size_t{dims}); // I guess this can be a compile-time static assert?
     for (int d = 0, d < dims, d++) {
        ASSERT_EQ(r.GlobalSize[d], global_range[d]);
        ASSERT_EQ(r.LocalSize[d], local_range[d]);
        ASSERT_EQ(r.GlobalOffset[d], offset[d]);
     }
  }
 ...
}

And then this function can be called thrice, once for each dimension, 1, 2, 3. That should reduce code duplication and would be easier to update it, if something changes in ranges_ref_view

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that's much better!

Unfortunately I can't use static_assert for the dimension check, constness should be improved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants