| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| 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)]); |
There was a problem hiding this comment.
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.
Sorry, something went wrong.
|
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 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. |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
| } | ||
|
|
||
| template <size_t ITEMS_PER_WORK_ITEM, load_algorithm ALGORITHM, typename InputT, | ||
| typename InputIteratorT, typename Item> |
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
thanks will add comments to clarify.
Sorry, something went wrong.
| // 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> . |
There was a problem hiding this comment.
can we rename to nd_item? (what is the diff b/w Item and sycl::nd_item)
Sorry, something went wrong.
There was a problem hiding this comment.
Yes it is same thing, but to maintain the same variable name across the file (similar for other apis), Item is used.
Sorry, something went wrong.
Co-authored-by: Wang, Zhiming <zhiming.wang@intel.com>
Co-authored-by: Wang, Zhiming <zhiming.wang@intel.com>
Co-authored-by: Wang, Zhiming <zhiming.wang@intel.com>
|
This PR is now tested with oneapi-src/SYCLomatic-test#619 and all tests are passing. |
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
In Progress PR for Load/Store header functions for Block API (related later to #1305 )
cc @yihanwg @danhoeflinger @mmichel11