-
Notifications
You must be signed in to change notification settings - Fork 787
[SYCL] Deprecate old sycl_ext_oneapi_group_load_store
#15405
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
[SYCL] Deprecate old sycl_ext_oneapi_group_load_store
#15405
Conversation
Newer version is under `proposed/`, I'm going to move it to `experimental/` in a separate PR for a cleaner `git diff`.
the documentation in its current state does not reflect the intended long-term | ||
direction of the extension. | ||
NOTE: This extension has been replaced with a new version under the same name | ||
that completely changed the interfaces. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the next PR, can you add a link here to the new spec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SYCL Joint Matrix changes looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for doing this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff!
LocOffsetA, | ||
slmVecA); | ||
vec<TOperand, 2> slmVecA; | ||
group_load(sg, SrcA, slmVecA, properties(data_placement_striped)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why did you choose here data_placement_striped instead of data_placement_blocked. Is the striped one the one that guarantees vectorization inside the SG?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I chose it because (IIUC) that matches the behavior of the old API. I didn't use the property for scalar overloads because both data layouts are essentially the same for scalars.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good if this is old API behavior.
It is weird then that by default, they made default placement is the blocked one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good if this is old API behavior.
Old:
Returns: Returns N elements per work-item, corresponding to the N memory locations at src + i * get_max_local_range() + get_local_id() for i between 0 and N.
New:
Effects: Loads N elements from in_iter to out using the g group object. Properties may specify data placement. Default data placement is a blocked one: out[i] = in_iter[g.get_local_linear_id() * N + i]; in striped case: out[i] = in_iter[g.get_local_linear_id() + g.get_local_linear_range() * i]; for i between 0 and N.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dont think there is any esimd specific interesting behavior here and the tests are passing
Newer version is under
proposed/
, I'm going to move it toexperimental/
in a separate PR for a cleanergit diff
.