Skip to content

[SYCL][NFC] Fix kernel release test when only host device is available #1835

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 2 commits into from
Jun 11, 2020

Conversation

sergey-semenov
Copy link
Contributor

PIMock should only be constructed from a non-host platform, make the
test check for a non-host platform prior to constructing PIMock.

Signed-off-by: Sergey Semenov sergey.semenov@intel.com

PIMock should only be constructed from a non-host platform, make the
test check for a non-host platform prior to constructing PIMock.

Signed-off-by: Sergey Semenov <sergey.semenov@intel.com>
@sergey-semenov sergey-semenov requested a review from a team as a code owner June 8, 2020 13:34
@sergey-semenov sergey-semenov requested a review from rbegam June 8, 2020 13:34
@sergey-semenov
Copy link
Contributor Author

@bader, this should take care of the post-commit failures https://github.com/intel/llvm/runs/747446124 . Although, I wonder why these tests are run there with no non-host devices in the first place.

Co-authored-by: Alexey Bader <alexey.bader@intel.com>
@bader
Copy link
Contributor

bader commented Jun 8, 2020

why these tests are run there with no non-host devices in the first place

This is valid use case for DPC++ and it's expected to work.
Moreover, I think unit tests should not rely on plug-ins or external dependencies to validate the SYCL library behavior.

@sergey-semenov
Copy link
Contributor Author

why these tests are run there with no non-host devices in the first place

This is valid use case for DPC++ and it's expected to work.

Sure, I just wouldn't expect it to be the only use case that's verified in post-commit (correct me if I'm wrong on that).

@sergey-semenov
Copy link
Contributor Author

Moreover, I think unit tests should not rely on plug-ins or external dependencies to validate the SYCL library behavior.

That would be ideal, it's a shame that PiMock doesn't offer that option right now.

@bader
Copy link
Contributor

bader commented Jun 8, 2020

why these tests are run there with no non-host devices in the first place

This is valid use case for DPC++ and it's expected to work.

Sure, I just wouldn't expect it to be the only use case that's verified in post-commit (correct me if I'm wrong on that).

What else do you think we should add to the post-commit?
NOTE#1: we have quite a lot testing in "pre-commit".
NOTE#2: Post-commit is configured here, feel free to propose any changes via PR.

@sergey-semenov
Copy link
Contributor Author

Ah, never mind, I've found the source of my confusion. I think our current setup is fine as is.

@sergey-semenov
Copy link
Contributor Author

@rbegam ping

@bader
Copy link
Contributor

bader commented Jun 11, 2020

@intel/llvm-reviewers-runtime, ping.

@bader
Copy link
Contributor

bader commented Jun 11, 2020

@smaslov-intel, thank you!

@bader bader merged commit 5c54a42 into intel:sycl Jun 11, 2020
FreddyLeaf pushed a commit to FreddyLeaf/llvm that referenced this pull request Mar 22, 2023
It specifies how to interpret 'Component Type' when components of a joint matrix are storages for values of different types, for example float for TF32, unsigned short for bfloat16.

At this point only tf32 type interpretation is added during SPIR-V generation. Adding it to bf16 is a breaking change and
requires adaptation across drivers.

Spec update:
intel#8175

Signed-off-by: Sidorov, Dmitry dmitry.sidorov@intel.com

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