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

[SYCL][DOC] Propose "get_kernel_info" extension #14472

Open
wants to merge 3 commits into
base: sycl
Choose a base branch
from

Conversation

gmlueck
Copy link
Contributor

@gmlueck gmlueck commented Jul 8, 2024

Add a proposed extension to query a kernel's information descriptor without creating a kernel bundle.

Add a proposed extension to query a kernel's information descriptor
without creating a kernel bundle.
@gmlueck gmlueck requested a review from a team as a code owner July 8, 2024 13:47
Also improve the wording for constraints.
don't think we want to mandate an error check at runtime.
In retrospect, I think this is the right behavior for the core SYCL spec also,
and we should consider changing the specified behavior.
Thoughts?
Copy link
Contributor

Choose a reason for hiding this comment

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

Which exceptions are these, specifically?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For example:

Preconditions: [...] The device dev must be one of the devices contained by ctxt. The kernel KernelName must be compatible with the device dev as defined by is_compatible.

In the existing SYCL 2020 spec, these error conditions mandate an exception:

  • An exception with the errc::invalid error code if any of the devices in devs is not one of devices contained by the context ctxt or is not a descendent device of some device in ctxt.

  • An exception with the errc::invalid error code if the kernel is not compatible with device dev (as defined by is_compatible())

However, this seems different from a _Constraint_, which is expected to result
in a compile-time error.
For now, I just listed it as a _Precondition_, so there is no formal
requirement for an implementation to diagnose this error.
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like the specification currently uses precondition for template argument requirements, so I think precondition is fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Seems like the specification currently uses precondition for template argument requirements

In the current SYCL 2020 specification, you mean? Yes, this is a bug in the specification, and it's my fault. I wrote that part of the specification before I understood the difference between Preconditions and Constraints. Those should be Constraints. It's on my list of things to clean up.

In the calls to `get_kernel_info` allow the device to be a descendent
device of the provided context.
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.

None yet

2 participants