-
Notifications
You must be signed in to change notification settings - Fork 353
Specify behavior of onSubmittedWorkDone/mapAsync on device loss #3937
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
| information and should never be parsed by applications. | ||
| </div> | ||
| 1. Complete any outstanding {{GPUBuffer/mapAsync()}} steps. | ||
| 1. Complete any outstanding {{GPUQueue/onSubmittedWorkDone()}} steps. |
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.
Bit handwavy but I think it's OK. There are cross-references in both directions between here and those steps.
| 1. Return. | ||
| 1. [=Assert=] |p| is still pending. | ||
| 1. Set |this|.{{GPUBuffer/[[pending_map]]}} to `null`, | ||
| and [=reject=] |p| with an {{OperationError}}. |
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.
This means we use an OperationError in the case of the device being lost. I think this is slightly better than AbortError because right now AbortError only happens with explicit cancellation in unmap().
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.
Agreed. You could make a case for AbortError if the device loss was caused by an explicit destroy but I don't think anyone wants to track it that closely, nor do I think it matters to developers at that point.
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.
device.destroy() will actually call buffer.unmap() which is supposed to cause an AbortError (if the map and the device.destroy were on the same thread). Something to test, I'll go ahead and file this so I can mention that.
GPU Web 2023-03-08
|
toji
left a comment
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.
Good refactoring of the steps. LGTM!
| 1. Return. | ||
| 1. [=Assert=] |p| is still pending. | ||
| 1. Set |this|.{{GPUBuffer/[[pending_map]]}} to `null`, | ||
| and [=reject=] |p| with an {{OperationError}}. |
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.
Agreed. You could make a case for AbortError if the device loss was caused by an explicit destroy but I don't think anyone wants to track it that closely, nor do I think it matters to developers at that point.
Issue: #1629