Skip to content

[SYCL] Avoid using intrinsics to get global id in stream #2318

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 1 commit into from
Aug 17, 2020

Conversation

againull
Copy link
Contributor

Avoid calling intrinsics to get global id when calculating the offset of
the work item in the flush buffer. When stream is used in a single_task
kernel this could cause an overhead on targets like FPGA. That is why
use global atomic variable to calcualte offsets.

Signed-off-by: Artur Gainullin [email protected]

Avoid calling intrinsics to get global id when calculating the offset of
the work item in the flush buffer. When stream is used in a single_task
kernel this could cause an overhead on targets like FPGA. That is why
use global atomic variable to calculate offsets.

Signed-off-by: Artur Gainullin <[email protected]>
@againull againull requested a review from a team as a code owner August 14, 2020 08:15
@againull againull requested a review from rbegam August 14, 2020 08:15
@bader
Copy link
Contributor

bader commented Aug 14, 2020

/summary:run

Copy link
Contributor

@s-kanaev s-kanaev 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

// Test to check that intrinsics to get a global id are not generated for the
// stream.

// CHECK-NOT: call spir_func void @{{.*}}__spirvL22initGlobalInvocationId{{.*}}
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit. I think you should check that there's no call to spirv initGlobalInvocationId inside the kernel. That means, that the kernel should still be there.

Copy link
Contributor

Choose a reason for hiding this comment

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

I didn't get this comment. This check covers all call instructions i.e. inside the kernel as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

What I mean is that if the frontend doesn't generate this instruction for some reason we have to be sure that the kernel is still generated. I believe that there are proper checks for that in frontend part of tests.

@bader bader merged commit 13e8dae into intel:sycl Aug 17, 2020
@againull againull deleted the single_task_stream branch December 3, 2022 00:03
jsji pushed a commit that referenced this pull request Feb 29, 2024
…eJointMatrixINTEL (#2318)

This PR is to ensure that CooperativeMatrixLoadCheckedINTEL, CooperativeMatrixStoreCheckedINTEL and CooperativeMatrixConstructCheckedINTEL instructions can correctly accept TypeJointMatrixINTEL as an input during both forward and reverse translation.

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@632c3f626990f36
Chenyang-L pushed a commit that referenced this pull request Feb 18, 2025
[L0 v2] fix native kernel handle interop
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