-
Notifications
You must be signed in to change notification settings - Fork 798
[SYCL][L0] Gracefully handle the case that L0 was already unloaded when we do cleanup #8948
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
@@ -97,6 +97,8 @@ _PI_ERRC(PI_ERROR_INVALID_VA_API_MEDIA_ADAPTER_INTEL, -1098) | |||
_PI_ERRC(PI_ERROR_INVALID_VA_API_MEDIA_SURFACE_INTEL, -1099) | |||
_PI_ERRC(PI_ERROR_VA_API_MEDIA_SURFACE_ALREADY_ACQUIRED_INTEL, -1100) | |||
_PI_ERRC(PI_ERROR_VA_API_MEDIA_SURFACE_NOT_ACQUIRED_INTEL, -1101) | |||
// backend is lost, e.g. it was already unloaded |
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.
nit: UNITIALIZED seems suitable for other scenarios as well, like backend is not found, or a library is not system.
…en we do cleanup Signed-off-by: Sergey V Maslov <sergey.v.maslov@intel.com>
auto ZeResult = ZE_CALL_NOCHECK(zeEventDestroy, (Event->ZeEvent)); | ||
// Gracefully handle the case that L0 was already unloaded. | ||
if (ZeResult && ZeResult != ZE_RESULT_ERROR_UNINITIALIZED) | ||
return mapError(ZeResult); |
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.
NIT: Does it make sense to create another macro like ZE_CALL/ZE_CALL_NOCHECK which will not fail in case of ZE_RESULT_ERROR_UNINITIALIZED to use it in finalize/release functions?
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 don't think so, it's very limited in number of uses and there are cases where you still need to do smth besides destroying L0 handles, e.g. https://github.com/intel/llvm/pull/8948/files#diff-15dd1eb076d2164bd9e87d9057f05f652a716498e8cdf5975e564c65309a0985R7438
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.
Ok
…en we do cleanup (intel#8948) Signed-off-by: Sergey V Maslov <sergey.v.maslov@intel.com>
No description provided.