[SYCL][Doc] Clarify WI funcs in kernel compiler #12891
Merged
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
Also disallows launching a SPIR-V kernel as a simple "range" kernel. This seems consistent with our view that a "range" kernel is not just a degenerate form of an nd-range kernel. Since SPIR-V kernels always have access to nd-range features, it does not make sense to launch them as range kernels. This is also consistent with our decision to limit SYCL free function kernels to "nd-range" and "single-task" forms.
The OpenCL table describing legal kernel arguments had the opposite order from the corresponding SPIR-V table. The OpenCL table listed the SYCL argument type in the left column while the SPIR-V table listed the SYCL argument tupe in the right column. I like the SPIR-V format better, so change the OpenCL table to match. This also adopts some of the same wording from the SPIR-V table into the OpenCL one.
Clarify the iteration space and the user of work-item functions in the OpenCL spec. These changes closely follow the corresponding changes in the SPIR-V spec.
Pennycook
requested changes
Mar 4, 2024
sycl/doc/extensions/experimental/sycl_ext_oneapi_kernel_compiler_opencl.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_kernel_compiler_opencl.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/experimental/sycl_ext_oneapi_kernel_compiler_opencl.asciidoc
Outdated
Show resolved
Hide resolved
Add a note referencing section C.7.7 of the core SYCL spec, which has more details about the inverted sense of SYCL dimensions compared to OpenCL.
Clarify that a single-task OpenCL and SPIR-V kernel can still use features like `local_accessor` and group functions. These are well-defined because we already state that these single-task kernels are launched as nd-range kernels with 1 work-item.
Pennycook
approved these changes
Mar 6, 2024
|
@intel/llvm-gatekeepers please merge #12888 before this one. I'll deal with the merge conflicts in this PR. |
Use [source] block instead of triple backticks.
|
@intel/llvm-gatekeepers: Conflicts are resolved. I think this is ready to merge. |
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.
Clarify the SPIR-V and OpenCL kernel compiler specifications to explain
how the SYCL iteration space maps to the SPIR-V / OpenCL C languages
and clarify that these kernels can use their normal language mechanisms
to find the current work-item's position in the iteration space.
We also disallow launching a SPIR-V or OpenCL C kernel as a simple
"range" kernel. This seems consistent with our view that a "range"
kernel is not just a degenerate form of an nd-range kernel. Since
SPIR-V and OpenCL C kernels always have access to nd-range features, it
does not make sense to launch them as range kernels. This is also
consistent with our decision to limit SYCL free function kernels to
"nd-range" and "single-task" forms.
Some other cleanup of these specifications also:
Clarify what happens when a
local_accessoris passed as a kernelargument to a SPIR-V or OpenCL kernel. This was causing some
confusion from users.
Reformat the table in the OpenCL spec describing kernel arguments
so that it has the same layout as the equivalent SPIR-V table.
Fix the name of the OpenCL header file in the example.