-
Notifications
You must be signed in to change notification settings - Fork 787
[SYCL] ext kernel compiler #11517
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] ext kernel compiler #11517
Conversation
…ore. But, most importantly, the PI which is the biggest hurdle this will face and is my next target. Better get a running start.
… new property list stuff in, error checking, testing, and other to-do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, but I would prefer extension doc to be merged first and explicit approval in this PR from @gmlueck ,
int InputArray[N] = {0, 1, 2, 3}; | ||
int OutputArray[N] = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
int InputArray[N] = {0, 1, 2, 3}; | |
int OutputArray[N] = {}; | |
cl_int InputArray[N] = {0, 1, 2, 3}; | |
cl_int OutputArray[N] = {}; |
I recently expanded the extension specification to list the rules for legal parameter types, and I realized that we should really be using the OpenCL types like cl_int
on the host. Check the types of your other kernel arguments too. See 41945cd for the details I added to the spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @cperkinsintel,
I saw that you requested re-review of this PR. Please see this comment I made above yesterday.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry about that @gmlueck , I didn't mean to ping you last night. I made the change now, using sycl::cl_int
(etc) instead of int
and friends in both the kernel_compiler.cpp test and the ocl_capabilities.cpp one.
I think I saw in the recent spec update that the example has #include <OpenCL/opencl.h>
to get the OpenCL types, but that shouldn't be necessary, correct? They are exposed in the sycl namespace. Let me know if I'm confusing anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the "cl_" types are not supposed to be exposed in the sycl
namespace. If our headers are doing that, it is a bug.
The SYCL OpenCL backend interop spec does say these types are available in the sycl::opencl
namespace, but that's only if the implementation supports the OpenCL backend. (DPC++ does, but that's not true for all SYCL implementations.) It's safest to include <OpenCL/opencl.h>
and then use the "cl_" types in the root namespace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Updated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't you also need #include <OpenCL/opencl.h>
?
@cperkinsintel: Can you also move the extension specifications to "experimental" as part of this PR? I believe both of these extensions are implemented by your PR, so they should both be moved:
In addition to moving them to the "experimental" directory, please also change the Status section to use the text from the extension template. |
@cperkinsintel There is a post-commit failure after this PR: https://github.com/intel/llvm/actions/runs/6857049804/job/18645408635 Could you please help to fix that? |
This patch fixes a regression caused by refactoring of `split_string` function in #11517. The regression is the following: the delimiter is a space, input string is `"A B C "` - which has a space at the end. Before #11517 `split_string` returned `{"A", "B", "C"}` but with #11517 it returns `{"A", "B", "C", ""}`. This regression affects multiple CTS tests, verified the fix locally, and also unit tests for `split_string` function were added to this patch. This log shows that one of the unit tests failed before applying the fix: https://github.com/intel/llvm/actions/runs/6974175043/job/18979466747#step:11:372. With the fix it passes. Fixes #11996
This is the implementation for the new "Kernel Compiler" which will replace the Online Compiler.
Its pending spec is here: #11331