Skip to content

[SYCL] Report an error message when "sycl::program::create_program_with_source" is used with Level-Zero #3212

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 9 commits into from
Feb 18, 2021

Conversation

rbegam
Copy link
Contributor

@rbegam rbegam commented Feb 12, 2021

Level-Zero backend does not support create_program_with_source. This is to report an error message from SYCL RT if that is requested.

Signed-off-by: rbegam [email protected]

…th_source"

is used with Level-Zero backend.

Signed-off-by: rbegam <[email protected]>
@rbegam rbegam requested a review from a team as a code owner February 12, 2021 21:11
@rbegam rbegam requested a review from vladimirlaz February 12, 2021 21:11
Signed-off-by: rbegam <[email protected]>
@rbegam rbegam requested a review from smaslov-intel February 12, 2021 21:47
if (Plugin.getBackend() == cl::sycl::backend::level_zero &&
Err == PI_INVALID_OPERATION) {
throw feature_not_supported(
"piclProgramCreateWithSource is not supported in Level Zero",
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
"piclProgramCreateWithSource is not supported in Level Zero",
"program::compile_with_source is not supported with Level Zero backend.",

We must not tell end users about PI interfaces. Also I think it would be good to redirect to the library that can be used to build OpenCL kernel for Level-Zero. @v-klochkov , which one is this?

Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this error be emitted from Level Zero plug-in, rather than from DPC++ runtime?

Copy link
Contributor

Choose a reason for hiding this comment

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

Plugins are C API. In order to throw a consistent error message this is better suited for SYCL RT, I think.

Copy link
Contributor

Choose a reason for hiding this comment

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

In order to throw a consistent error message this is better suited for SYCL RT, I think.

Right, but BE specific error detection logic must be located in corresponding plug-in. DPC++ runtime is designed to keep device specific logic in plug-ins and logic common for all back-ends in "runtime" library.
To follow this design we can separate error detection logic (device specific) from error reporting/conversion logic (common for all plug-ins).
E.g. plug-in can return an error code when "compile with source" feature is not supported (PI_INVALID_OPERATION? or some other error code) and DPC++ runtime can report this error via exception - "program::compile_with_source is not supported with" + Plugin.getBackend().to_string()" - this is a pseudo code to demonstrate the idea, not a real C++ program.

Basically code like this:

if (Plugin.getBackend() == cl::sycl::backend::<some_backend>) {
...
}

is a red flag signaling that most likely it should be implemented in corresponding plug-in.

Copy link
Contributor

Choose a reason for hiding this comment

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

That's right. We don't need to check the backend here in SYCL RT, every backend would return PI_INVALID_OPERATION of compilation is not supported, and the error message would be common for all such backends. @rbegam , please also change CUDA plugin to do the same, i.e. return an error:

Copy link
Contributor

Choose a reason for hiding this comment

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

Also I think it would be good to redirect to the library that can be used to build OpenCL kernel for Level-Zero. @v-klochkov , which one is this?

The class sycl::INTEL::online_compiler can generate IL/SPIR-V for a source program.

Signed-off-by: rbegam <[email protected]>
@rbegam rbegam requested a review from a team as a code owner February 16, 2021 19:44
Signed-off-by: rbegam <[email protected]>
@@ -2650,7 +2650,7 @@ pi_result cuda_piclProgramCreateWithSource(pi_context context, pi_uint32 count,
const size_t *lengths,
pi_program *program) {
cl::sycl::detail::pi::die("cuda_piclProgramCreateWithSource not implemented");
Copy link
Contributor

Choose a reason for hiding this comment

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

remove the die, since it makes the return unreachable

Copy link
Contributor Author

Choose a reason for hiding this comment

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

right, will do that. should I enable printing the error msg here (like level_zero) before returning? There are some more cases in the cuda plugin where die() is called before a return stmt with an error code. might be a good idea to fix those too.

Copy link
Contributor

Choose a reason for hiding this comment

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

should I enable printing the error msg here (like level_zero) before returning?

Why not, if they have the ways to print logs.

There are some more cases in the cuda plugin where die() is called before a return stmt with an error code. might be a good idea to fix those too.

Let's not remove any "die"-s without making sure they (error return codes) are handled properly in SYCL RT.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why not, if they have the ways to print

there is no way right now just for printing error msg.

@@ -26,6 +27,21 @@ __SYCL_INLINE_NAMESPACE(cl) {
namespace sycl {
namespace detail {

inline const std::string GetBackendString(cl::sycl::backend backend) {
Copy link
Contributor

Choose a reason for hiding this comment

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

if you really wanted to name the backend in the error message (I don't feel this is necessary) then you'd employ the existing

inline std::ostream &operator<<(std::ostream &Out, backend be) {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll skip this if not necessary.

Copy link
Contributor

@vladimirlaz vladimirlaz left a comment

Choose a reason for hiding this comment

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

@rbegam, could you please fix the clang-format issue

Signed-off-by: rbegam <[email protected]>
Signed-off-by: rbegam <[email protected]>
Signed-off-by: rbegam <[email protected]>
MContext->getHandleRef(), 1, &Src, &Size, &MProgram);

if (Err == PI_INVALID_OPERATION) {
throw feature_not_supported("program::compile_with_source is not supported",
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
throw feature_not_supported("program::compile_with_source is not supported",
throw feature_not_supported("program::compile_with_source is not supported by the selected backend",

smaslov-intel
smaslov-intel previously approved these changes Feb 17, 2021
Signed-off-by: rbegam <[email protected]>
smaslov-intel
smaslov-intel previously approved these changes Feb 17, 2021
Copy link
Contributor

@smaslov-intel smaslov-intel left a comment

Choose a reason for hiding this comment

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

LGTM

Signed-off-by: rbegam <[email protected]>
@bader bader merged commit ba77e3a into intel:sycl Feb 18, 2021
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.

5 participants