-
Notifications
You must be signed in to change notification settings - Fork 797
[SYCL][UR][CUDA] Mirror SYCL_PI env vars with UR prefix #10045
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
Conversation
As a side note, does that mean that |
@@ -39,7 +39,8 @@ ur_result_t checkErrorUR(CUresult Result, const char *Function, int Line, | |||
return UR_RESULT_SUCCESS; | |||
} | |||
|
|||
if (std::getenv("SYCL_PI_SUPPRESS_ERROR_MESSAGE") == nullptr) { | |||
if (std::getenv("SYCL_PI_SUPPRESS_ERROR_MESSAGE") == nullptr || | |||
std::getenv("UR_SUPPRESS_ERROR_MESSAGE") == nullptr) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be UR_CUDA_SUPPRESS_ERROR_MESSAGE? if it is UR_ prefixed, should we have it officially documented in the UR spec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ummm, this is apparently only intended for CI, so I dont think it should be in the spec, or if we need it in UR (do we want to have it in the future UR CI?) Change is good for now, but we might need to think eventually if we want to carry it over to UR CI.
| SYCL_PI_SUPPRESS_ERROR_MESSAGE
| Any(*) | Suppress printing of error message, only used for CI in order not to interrupt errors generated by underlying toolchains;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left it as UR_ for now, I think we'll be revisiting native error handling in the CUDA adapter soon which seems like a good opportunity to think about this again
right, eventually, but we need to allow for the use of both at the same time while we are in transition. I guess we need to select a specific release by which the SYCL_PI_ wont be accepted anymore. Related: I have this PR where I'm updating the documentation for the L0 variables #9350 |
@callumfare, please, resolve, merge conflicts. |
4bf6acd
to
2326bd1
Compare
@bader The conflicts are resolved now, this is ready to merge |
No description provided.