-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
No longer silently hide errors in Metal completion handlers (alternative approach) #8240
No longer silently hide errors in Metal completion handlers (alternative approach) #8240
Conversation
Sorry @steven-johnson, I brain-farted and hadn't pushed the branch I intended to push when I opened this. Should be correct now. |
@shoaibkamil I recommend pre-pending the error message with something that reminds the user that this error has happened unexpectedly during the execution of a previous pipeline. |
|
…pletion_handler_error_alternative
@steven-johnson I've substantially revamped the API here to enable users to pass a user context. PTAL |
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.
LGTM pending green buildbots
Investigating crash, and will add tests to makefile. |
…ns out to be much simpler than I thought
All green finally, modulor vulkan errors. |
As discussed in the dev meeting, here is an alternative approach for fixing #7780. Now, the runtime saves an error during the callback from a failed command buffer, and reports the error back at the next opportunity for reporting. Note that this means that a pipeline may get an error that should be attributed to the previous pipeline, but additional error information can be added (e.g. prepending the error message with the name of the kernel that caused it) if wanted.