Clarify is_available
#740
Open
Clarify is_available
#740
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The is_available query is based on CL_DEVICE_AVAILABLE from OpenCL. The most recent OpenCL standard includes the sentence added by this commit.
gmlueck
approved these changes
Feb 28, 2025
+1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
is_availablequery is based onCL_DEVICE_AVAILABLEfrom OpenCL. The most recent OpenCL standard includes an extra sentence that wasn't copied over to SYCL 2020, and this PR fixes that.I also added an extra sentence to clarify that what causes a device to move between available and not available is implementation-defined. This wasn't part of OpenCL, but I can't see a way to avoid specifying it this way in SYCL: the least surprising way to implement this on an OpenCL backend would be to say "It returns the result of
CL_DEVICE_AVAILABLE", but that is only possible if it's implementation-defined.Closes #347.
My personal opinion is that this query isn't very useful, and that we should deprecate it and remove it in SYCL-Next. But that's a separate issue to what the behavior should be in SYCL 2020.