Add GPUDevice.destroy() - #1316
Conversation
|
What about the pending callbacks, e.g. from buffer mapping? Would they be dropped on the ground with this call? |
|
I think the algorithms for those could probably say e.g. "if the device is lost, reject with ...".
Though maybe we want to put them all in a central location to get rejected (that's more accurate to the implementation). |
| It may become [=invalid=] during its lifetime, but it will never become valid again. | ||
|
|
||
| Issue: Consider separating "invalid" from "destroyed". | ||
| This would let validity be immutable, and only operations involving devices, |
There was a problem hiding this comment.
Destroying the device would also prevent submitting work on the queue for example.
|
|
||
| 1. Make |this|.{{GPUDevice/[[device]]}} [=invalid=]. | ||
|
|
||
| Note: This does **not** resolve |this|.{{GPUDevice/lost}}. |
There was a problem hiding this comment.
What's the reasoning behind this?
There was a problem hiding this comment.
I don't think it's useful to send a signal back to the app in response to it destroying the device. .lost is not a promise you would await in the middle of some logic, so there's no danger in leaving it unresolved forever - its resolution is meant to be a signal to recover from device loss. If we did resolve it on destroy, then apps would have to go out of their way to prevent their own explicit-destroy from triggering recovery logic.
|
Resolution: propose having .lost fire on destroy(), give it a parameter about why it was lost (naturally or by destroy()). |
Done, PTAL. @austinEng fyi |
Like other
.destroy()methods, immediately destroys the device and makes it invalid for future use (i.e. lost, though it doesn't fire the.lostpromise).This allows for eager cleanup of an entire device and its resources.
Preview | Diff