requestDevice returns null if adapter is lost #521
Conversation
| } catch (e) { | ||
| console.error("device request failed", e); | ||
| // That failed; try a new adapter entirely. | ||
| await tryEnsureDeviceOnCurrentAdapter(); |
There was a problem hiding this comment.
nit: this call to tryEnsureDeviceOnCurrentAdapter() can be folded inside the loop.
There was a problem hiding this comment.
The first one tries to reuse the current adapter while the later ones get a new adapter, though maybe this is wrong. I think this code still needs some revision.
|
TODO: Investigate making requestAdapter return null if no adapters are available. |
|
This was discussed in the 2020-01-06 meeting |
| An app should never give up on getting WebGPU access due to | ||
| `requestDevice` returning null or `GPUDevice.lost` resolving. | ||
| It should only give up based on a `requestAdapter` rejection. | ||
| (It should also give up on a `requestDevice` rejection, as that indicates an app programming error.) |
There was a problem hiding this comment.
It feels to me that "should give up" and "shouldn't give up" distinction is too high level. We could maybe specify it in terms of "this is a function of Xxx", which implies to the user whether they should try again or not. I.e. we can say that the rejection is deterministic based on the adapter capabilities and the provided options. This is better than "should give up" because it also allows for a case where the user probes for different limits, so they would actually want to try again with different options.
At the same time, we'd say that returning null is an indication of a temporary state that doesn't depend on the parameters.
There was a problem hiding this comment.
(this is just the design doc, so we can make it more formal in spec)
requestDevice rejects if you ask for higher limits than its adapter has. Apps shouldn't be doing that (they should check the adapter limits instead) making this rejection an app programming error.
requestAdapter rejects if no adapters could possibly be returned. Given the only adapter request option right now is powerPreference, the options should never have an impact on whether or not you get an adapter. Perhaps in the future it would though.
|
Discussed today. Resolution: merge! |
If a texture format support multisample, it should be renderable: color-renderable, depth-renderable, or stencil-renderable. See gpuweb issue at gpuweb#1522. This change will fix Dawn issue 731: https://bugs.chromium.org/p/dawn/issues/detail?id=731.
This means all rejections from requestAdapter/requestDevice are "give up on webgpu" scenarios, simplifying the logic.