Skip to content
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

Add sycl_khr_group_interface extension #638

Open
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

Pennycook
Copy link
Contributor

This extension introduces an alternative interface for groups of work-items, offering several improvements over the SYCL 2020 interface:

  • Shorter names for member functions, dropping the get_ prefix.

  • Cleaner separation between properties of a group (e.g., a group id) and properties of the calling work-item (e.g., its id within a group).

  • Clearer distinction between "group" concept and "work_group" class.

  • New work_item class to represent a single work-item within a specific parent group. This class also satisfies the group concept, modeling a group containing a single work-item.

This extension introduces an alternative interface for groups of
work-items, offering several improvements over the SYCL 2020 interface:

- Shorter names for member functions, dropping the get_ prefix.

- Cleaner separation between properties of a group (e.g., a group id)
  and properties of the calling work-item (e.g., its id within a group).

- Clearer distinction between "group" concept and "work_group" class.

- New work_item class to represent a single work-item within a specific
  parent group. This class also satisfies the group concept, modeling
  a group containing a single work-item.
@Pennycook Pennycook force-pushed the khr_group_interface branch from dc92d73 to 93e784e Compare October 4, 2024 10:40
khr::work_item is not templated on dimensions.
The synopsis previously assumed that the extents would be one
dimensional, but it must match the ParentGroup. There is no suitable
shorthand alias or exposition-only description for this case defined
by mdspan, so replace the type with a comment.
@TApplencourt
Copy link
Contributor

TApplencourt commented Oct 7, 2024

I like the usage of namespace.

    khr::work_group<1> g = ndit.get_group();
    khr::work_item it = get_item(g);

Few questions (sorry, trying to understand this new khr mechanism), should it be :

  • khr::group_interface::work_item
  • ndit.khr_group_interface_get_group? (or just ndit.khr_get_group()?)
  • khr::group_interface::get_item?

@Pennycook
Copy link
Contributor Author

I like the usage of namespace.

    khr::work_group<1> g = ndit.get_group();
    khr::work_item it = get_item(g);

Few questions (sorry, trying to understand this new khr mechanism), should it be :

  • khr::group_interface::work_item
  • ndit.khr_group_interface_get_group? (or just ndit.khr_get_group()?)
  • khr::group_interface::get_item?

I don't think so. When vendors introduce extensions they use sycl::ext::vendor::, not sycl::ext::vendor::extension_name.

The way I see it, although putting something in the khr:: namespace reserves a name, the SYCL WG is in complete control over any names that are introduced there. Future extensions might have to be more creative with their naming, but there's no risk of surprise conflicts.

Copy link
Member

@keryell keryell left a comment

Choose a reason for hiding this comment

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

That looks good!

@keryell
Copy link
Member

keryell commented Dec 5, 2024

Adding the 2 rank functions from mdspan too? https://gitlab.khronos.org/sycl/Specification/-/issues/630

rank(), rank_dynamic() and static_extent() are all exposed as static
member functions in mdspan, so we follow that precedent here.
@Pennycook
Copy link
Contributor Author

Adding the 2 rank functions from mdspan too? https://gitlab.khronos.org/sycl/Specification/-/issues/630

Good idea. I've added rank, rank_dynamic and static_extent in 008ac23.

@Pennycook Pennycook force-pushed the khr_group_interface branch from 25b35fe to d59ccb9 Compare December 6, 2024 11:46
adoc/extensions/sycl_khr_group_interface.adoc Outdated Show resolved Hide resolved
adoc/extensions/sycl_khr_group_interface.adoc Outdated Show resolved Hide resolved
adoc/extensions/sycl_khr_group_interface.adoc Outdated Show resolved Hide resolved
adoc/extensions/sycl_khr_group_interface.adoc Outdated Show resolved Hide resolved
adoc/extensions/sycl_khr_group_interface.adoc Show resolved Hide resolved
adoc/extensions/sycl_khr_group_interface.adoc Outdated Show resolved Hide resolved
adoc/extensions/sycl_khr_group_interface.adoc Outdated Show resolved Hide resolved
adoc/extensions/sycl_khr_group_interface.adoc Show resolved Hide resolved
adoc/extensions/sycl_khr_group_interface.adoc Outdated Show resolved Hide resolved
adoc/extensions/sycl_khr_group_interface.adoc Outdated Show resolved Hide resolved
The previous "not user constructible" wording was based on the description of
existing group types. The new wording explains why khr::group, khr::sub_group,
and khr::work_item have limited constructors and also points to functions that
can be used to acquire instances of these types.
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.

4 participants