Skip to content

Conversation

abhilash1910
Copy link
Contributor

In Progress PR for Load/Store header functions for Block API (related later to #1305 )
cc @yihanwg @danhoeflinger @mmichel11

@abhilash1910 abhilash1910 requested a review from a team as a code owner January 18, 2024 12:23
@abhilash1910 abhilash1910 marked this pull request as draft January 18, 2024 12:24
@abhilash1910 abhilash1910 changed the title [SYCLomatic] Block Load/Store headers core [SYCLomatic] Block Load headers core Jan 29, 2024
@abhilash1910 abhilash1910 marked this pull request as ready for review January 29, 2024 15:35
for (int ITEM = 0; ITEM < ITEMS_PER_THREAD; ITEM++) {
new (&items[ITEM])
InputT(block_itr[item.get_sub_group().get_local_range()[0] +
linear_tid + (ITEM * ITEMS_PER_THREAD)]);
Copy link
Contributor

@mmichel11 mmichel11 Feb 1, 2024

Choose a reason for hiding this comment

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

A similar comment to above with regards to the stride. In this case, I believe instead of ITEMS_PER_THREAD it should be the subgroup size.

@mmichel11
Copy link
Contributor

mmichel11 commented Feb 2, 2024

Thinking about the design in more depth, I do not think these APIs should be implemented as free functions. Rather, I think they should be implemented as classes which overload the function call operator or have a member function that invokes the load operation.

My reasoning for this is that certain applications during migration may need to pass a "load" object to a separate function
/ routine in a kernel. If they are implemented as classes, then an object can be passed to the function where it could then be used:

load_striped<...> obj;
my_func(obj);

However, if they are implemented as free functions, then they would need to be passed as function pointers:

auto func_obj = &load_striped<...>;
my_func(func_obj);

which is not supported in the SYCL programming model. To make this work, load_striped would have to be called directly from my_func which I think may be difficult from the migration perspective.

What I think we should do is have two classes work_group_load and sub_group_load and then have some enum type dictating the strategy (ex: striped, blocked, etc). We could then have have specializations of this class to implement each strategy and maybe have some helpers to reduce code duplication.

Copy link
Contributor

@yihanwg yihanwg left a comment

Choose a reason for hiding this comment

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

LGTM

@mmichel11
Copy link
Contributor

mmichel11 commented Apr 30, 2024

This PR looks to be in good shape for me. However, I think the outstanding comments in oneapi-src/SYCLomatic-test#619 need to be addressed, so we can have confidence in the implementation's correctness.

}

template <size_t ITEMS_PER_WORK_ITEM, load_algorithm ALGORITHM, typename InputT,
typename InputIteratorT, typename Item>
Copy link
Contributor

Choose a reason for hiding this comment

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

here are quite many item usage, ITEM/Item/iterms/ITERMS_PER_WORK_ITEM, maybe it should give a better name for "typename Item", it is a little confusing. or please add comments.

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 will add comments to clarify.

// InputT: typename parameter controlled at runtime from input sequence.
// InputIteratorT: typename parameter for iterator pointer controlled at
// runtime.
// Item : typename parameter resembling sycl::nd_item<3> .
Copy link
Contributor

Choose a reason for hiding this comment

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

can we rename to nd_item? (what is the diff b/w Item and sycl::nd_item)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes it is same thing, but to maintain the same variable name across the file (similar for other apis), Item is used.

@abhilash1910
Copy link
Contributor Author

This PR is now tested with oneapi-src/SYCLomatic-test#619 and all tests are passing.
Tested on application side as well, working as expected.

Copy link
Contributor

@danhoeflinger danhoeflinger left a comment

Choose a reason for hiding this comment

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

LGTM,
There are some changes needed in the testing PR still, but with some local changes to those tests and passing runs, I'm confident enough in this PR now to approve.

Copy link
Contributor

@mmichel11 mmichel11 left a comment

Choose a reason for hiding this comment

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

LGTM

@zhimingwang36 zhimingwang36 merged commit 01f2906 into oneapi-src:SYCLomatic May 9, 2024
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.

5 participants