Skip to content

[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

Merged
merged 41 commits into from
Nov 13, 2023

Conversation

cperkinsintel
Copy link
Contributor

This is the implementation for the new "Kernel Compiler" which will replace the Online Compiler.
Its pending spec is here: #11331

@cperkinsintel cperkinsintel requested a review from gmlueck October 12, 2023 04:42
@cperkinsintel cperkinsintel temporarily deployed to WindowsCILock October 12, 2023 23:32 — with GitHub Actions Inactive
Copy link
Contributor

@againull againull left a 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 ,

Comment on lines 57 to 58
int InputArray[N] = {0, 1, 2, 3};
int OutputArray[N] = {};
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks. Updated

Copy link
Contributor

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>?

@gmlueck
Copy link
Contributor

gmlueck commented Nov 13, 2023

@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 cperkinsintel requested a review from a team as a code owner November 13, 2023 20:49
@againull againull merged commit 096676e into intel:sycl Nov 13, 2023
@againull
Copy link
Contributor

@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?

dm-vodopyanov added a commit that referenced this pull request Nov 27, 2023
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
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.

3 participants