Skip to content

[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

Merged

Conversation

aelovikov-intel
Copy link
Contributor

Newer version is under proposed/, I'm going to move it to experimental/ in a separate PR for a cleaner git diff.

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.
Copy link
Contributor

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?

@aelovikov-intel aelovikov-intel marked this pull request as draft September 16, 2024 20:42
@aelovikov-intel aelovikov-intel marked this pull request as ready for review September 16, 2024 20:48
Copy link
Contributor

@YuriPlyakhin YuriPlyakhin left a 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.

Copy link
Contributor

@Pennycook Pennycook left a 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!

Copy link
Contributor

@steffenlarsen steffenlarsen left a 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));
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

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 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.

Copy link
Contributor

@sarnex sarnex left a 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

@aelovikov-intel aelovikov-intel merged commit f39f1de into intel:sycl Sep 17, 2024
13 checks passed
@aelovikov-intel aelovikov-intel deleted the deprecate-old-group-load-store branch September 17, 2024 16:53
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.

7 participants