Skip to content

[SYCL] Add OpenCL interop API following SYCL-2020 backend generalization #1846

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 3 commits into from
Jun 17, 2020

Conversation

smaslov-intel
Copy link
Contributor

The implementation is following https://github.com/KhronosGroup/SYCL-Shared/blob/master/proposals/sycl_generalization.md.

It is OpenCL centric, and a Level-Zero counterpart is coming here: #1723

An important "side-effect" is that plugins are initialized from these APIs and not only from get_platforms() in the current state.

Signed-off-by: Sergey V Maslov [email protected]

@smaslov-intel smaslov-intel requested a review from a team as a code owner June 9, 2020 15:16
@smaslov-intel smaslov-intel requested a review from rbegam June 9, 2020 15:16
Copy link
Contributor

@steffenlarsen steffenlarsen left a comment

Choose a reason for hiding this comment

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

A few comments but otherwise LGTM.

@smaslov-intel smaslov-intel force-pushed the opencl_interop branch 3 times, most recently from f6acb77 to c57acef Compare June 10, 2020 14:43
Copy link
Contributor

@rbegam rbegam left a comment

Choose a reason for hiding this comment

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

LGTM

@smaslov-intel
Copy link
Contributor Author

Sorry for force-push. Re-based on top of recently merged #1868 which is essential for the getPlugin<> here to work correctly.

Copy link
Contributor

@nyalloc nyalloc left a comment

Choose a reason for hiding this comment

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

Good to see this stuff in the OpenCL backend now.

@smaslov-intel
Copy link
Contributor Author

Can someone tell what are the fails in buildbot/Lit_With_Cuda, and how to reproduce them locally? Tagging @bader too

@smaslov-intel
Copy link
Contributor Author

smaslov-intel commented Jun 15, 2020

@alexanderfle , do you think this might be related to #1872 (comment)?

@alexanderfle
Copy link
Contributor

@smaslov-intel , As for me, I don’t see any connections here except the same buildbot output of the LIT_With_Cuda for one of my commit.

@smaslov-intel
Copy link
Contributor Author

smaslov-intel commented Jun 15, 2020

except the same buildbot output of the LIT_With_Cuda

@alexanderfle, can you see in the output what failed and how?

@alexanderfle
Copy link
Contributor

can you see in the output what failed and how?

No, and I have the same questions:

Can someone tell what are the fails in buildbot/Lit_With_Cuda, and how to reproduce them locally?

Copy link
Contributor

@alexbatashev alexbatashev left a comment

Choose a reason for hiding this comment

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

LGTM

@bader bader merged commit bae0639 into intel:sycl Jun 17, 2020
FreddyLeaf pushed a commit to FreddyLeaf/llvm that referenced this pull request Mar 22, 2023
This patch implements the initial support for the new debug specification NonSemantic.Kernel.DebugInfo.100.
It also introduces support for the new debug instruction DISubrange.

Spec: KhronosGroup/SPIRV-Registry#186

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@daad382
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