Repository navigation
CTS expects wrong result of mapAsync on invalid buffer #4708
Description
Activity
cc @kainino0x
I think this is a spec typo, and it was meant to say
this.[[device]] must be valid.Right now, the spec says "if buffer is invalid, set deviceLost=true", which doesn't make any sense.
But we should still be check buffer validity, no?
EDIT: Usually we do https://www.w3.org/TR/webgpu/#abstract-opdef-valid-to-use-with, but maybe we want separate errors for device invalid vs. buffer invalid
there also does not seem to be any test for mapAsnyc on destroyed device
But we should still be check buffer validity, no?
Ah yes, true... probably accidentally missed that because the
this must be validof course makes it look like it is checked. It could also be the case that at some point I thoughtthis.[[internal state]] is "available"requirement would check that. It doesn't, though.there also does not seem to be any test for mapAsnyc on destroyed device
Offhand I'm not sure, but you're probably right.
I prepared spec update gpuweb/gpuweb#10971 which raise AbortError (deviceLost=true) when device is invalid (lost) and raise OperationError on invalid buffer (in that order) as I think that was the original intention. Based on new CTS test this also matches the behavior of dawn.
On invalid buffer CTS expects:
cts/src/webgpu/api/validation/buffer/mapping.spec.ts
Line 155 in 81aeeb4
and both firefox and chromium pass it, but spec says we should return abort and no validation error:
This might also be spec issue as introduction PR of spec text talks about device loss, but here it's actually buffer invalidity part of code: gpuweb/gpuweb#5114 (
thisis buffer not device).