Conversation
ac3de40 to
cc1b179
Compare
| should never trigger multiple competing signals, | ||
| so it is safe to handle each such signal individually. | ||
| (For example, a system event may trigger multiple {{GPUDevice/lost}} signals, | ||
| but not both {{GPU/adapteradded}} and {{GPUDevice/lost}}.) |
There was a problem hiding this comment.
Is a reboot of an external GPU a single event or two?
There was a problem hiding this comment.
Good question. It would have to be two: adapter loss and adapter added. We would at least need to ensure those events arrive in order.
Even if these are spaced far enough apart that they don't collide, there is a problem: when the adapter comes back, if a promise from getAdapter() is still waiting (e.g. because it's waiting for the reset to finish), then there will be two signals: adapteradded and the resolution of the promise.
There was a problem hiding this comment.
#524 (comment) may solve this [EDIT: don't think so]
There was a problem hiding this comment.
One way to handle this: don't fire adapteradded on device resets. If an app did requestAdapters() after a device reset it would see a new GPUAdapter object, but it would not be a different physical device so it doesn't actually care.
There was a problem hiding this comment.
Actually, as one TODO in the doc says, I don't think there's a reason to actually lose the adapter on reset. We can just lose all the devices on the adapter without replacing the adapter itself. So then there is no reason to expect adapteradded would fire anyway.
3b2169c to
430de7d
Compare
430de7d to
c6373f8
Compare
|
This was discussed in the 2020-01-06 meeting |
|
Resolution: further consider onadapterschanged |
9126022 to
992d5c7
Compare
992d5c7 to
fec4764
Compare
Preview | Diff