Skip to content

[SYCL] Deprecate fallback assertions #18310

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

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

Conversation

steffenlarsen
Copy link
Contributor

@steffenlarsen steffenlarsen commented May 5, 2025

This commit deprecates (and removes under preview flag) the fallback assertion implementation for SYCL kernels. The expected behavior after this is that backends that do not support native asserts, as reported through the ext_oneapi_native_assert aspect, will ignore assertions in kernel code.

This commit also makes the L0 adapter report support for native assert, as it was incorrectly reporting false before.

This commit deprecates (and removes under preview flag) the fallback
assertion implementation for SYCL kernels. The expected behavior after
this is that backends that do not support native asserts, as reported
through the ext_oneapi_native_assert aspect, will ignore assertions in
kernel code.

Signed-off-by: Larsen, Steffen <[email protected]>
@npmiller
Copy link
Contributor

npmiller commented May 5, 2025

I believe these two tests also rely on the fallback asserts:

Or at least they used to, I'm not sure the current checks represent that intent, and they never had the macros defined. But you can see the comment for the cuda/hip unsupported. And fallback is really the only case that would make sense to test for discard events with assert since it adds extra commands that might add/use events. I've been meaning to dig further into them to re-enable them for CUDA and HIP, but if we're dropping fallback we might be able to just delete these eventually.

@gmlueck
Copy link
Contributor

gmlueck commented May 5, 2025

What is our plan for the assert feature once the environment variable is removed? Will assert statements simply be silently ignored if they appear in a kernel that is submitted to a device without native support? If that is the case, I think we need an update to the sycl_ext_oneapi_assert specification.

Or, will assert be treated like other device-optional features, and the implementation will throw an exception if the device does not support it? In this case, we would also need an update to sycl_ext_oneapi_assert.

@jbrodman
Copy link
Contributor

jbrodman commented May 5, 2025

I believe these two tests also rely on the fallback asserts:

Or at least they used to, I'm not sure the current checks represent that intent, and they never had the macros defined. But you can see the comment for the cuda/hip unsupported. And fallback is really the only case that would make sense to test for discard events with assert since it adds extra commands that might add/use events. I've been meaning to dig further into them to re-enable them for CUDA and HIP, but if we're dropping fallback we might be able to just delete these eventually.

We'd ultimately like to get rid of DiscardEvents too...

Signed-off-by: Larsen, Steffen <[email protected]>
@steffenlarsen steffenlarsen requested review from a team as code owners May 5, 2025 16:03
@steffenlarsen
Copy link
Contributor Author

What is our plan for the assert feature once the environment variable is removed? Will assert statements simply be silently ignored if they appear in a kernel that is submitted to a device without native support? If that is the case, I think we need an update to the sycl_ext_oneapi_assert specification.

This seems like the safest solution to me, as it means users can still run their kernels on devices where they would run before, even if we can't do the asserts in there for them. I've updated the extension.

Signed-off-by: Larsen, Steffen <[email protected]>
Signed-off-by: Larsen, Steffen <[email protected]>
Signed-off-by: Larsen, Steffen <[email protected]>
Signed-off-by: Larsen, Steffen <[email protected]>
Signed-off-by: Larsen, Steffen <[email protected]>
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