Message queueing follow-ups
Categories
(Core :: Graphics: WebGPU, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox143 | --- | fixed |
People
(Reporter: teoxoy, Assigned: teoxoy)
References
(Regressed 1 open bug)
Details
Attachments
(13 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
Bug 1975714 - Do not immediately resolve the lost promise on `device.destroy()`. r=#webgpu-reviewers
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Follow-ups to Bug 1968122, mainly addressing issues brought up in reviews.
| Assignee | ||
Comment 1•10 months ago
|
||
| Assignee | ||
Comment 2•10 months ago
|
||
We can't immediately resolve the lost promise on device.destroy()
since it has to be well-ordered with the resolution of other promises.
I previously mentioned I had to demote 2 tests from tier 2 because I
thought they were relying on promise ordering that the spec doesn't
guarantee. Looking at the spec more throughly it turns out that the
specific steps outlined in the spec do guarantee the ordering but
the more succint "Promise Ordering" section does not mention this.
Tests in question:
https://gpuweb.github.io/cts/standalone/?q=webgpu:api,validation,state,device_lost,destroy:createComputePipelineAsync:*
https://gpuweb.github.io/cts/standalone/?q=webgpu:api,validation,state,device_lost,destroy:createRenderPipelineAsync:*
| Assignee | ||
Comment 3•10 months ago
|
||
| Assignee | ||
Comment 4•10 months ago
|
||
| Assignee | ||
Updated•10 months ago
|
Updated•10 months ago
|
| Assignee | ||
Comment 5•10 months ago
|
||
| Assignee | ||
Comment 6•10 months ago
|
||
| Assignee | ||
Comment 7•10 months ago
|
||
| Assignee | ||
Comment 8•10 months ago
|
||
| Assignee | ||
Comment 9•10 months ago
|
||
| Assignee | ||
Comment 10•10 months ago
|
||
| Assignee | ||
Comment 11•10 months ago
|
||
| Assignee | ||
Comment 12•10 months ago
|
||
Most of the new passes are due to us now rejecting async pipeline creation promises with the correct error (GPUPipelineError).
| Assignee | ||
Comment 13•10 months ago
|
||
Comment 14•10 months ago
|
||
Comment 15•10 months ago
|
||
Comment 16•10 months ago
|
||
Backed out for causing build bustages @ ComputePassEncoder.cpp
Backout link: https://hg.mozilla.org/integration/autoland/rev/2c28b9cc7958a8e70082af1bf460dc10b8fed061
| Assignee | ||
Updated•10 months ago
|
Comment 17•10 months ago
|
||
Comment 18•9 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/6a603737cd3b
https://hg.mozilla.org/mozilla-central/rev/3eaca7e39df9
https://hg.mozilla.org/mozilla-central/rev/516dbb695466
https://hg.mozilla.org/mozilla-central/rev/9da0b548679b
https://hg.mozilla.org/mozilla-central/rev/75c05347f9cd
https://hg.mozilla.org/mozilla-central/rev/27ea7465eb6c
https://hg.mozilla.org/mozilla-central/rev/93e62f967dbd
https://hg.mozilla.org/mozilla-central/rev/a8b3ec80998f
https://hg.mozilla.org/mozilla-central/rev/adff87de88aa
https://hg.mozilla.org/mozilla-central/rev/d20e5910cdbf
https://hg.mozilla.org/mozilla-central/rev/ef60c31a43b2
https://hg.mozilla.org/mozilla-central/rev/0594b5f63104
https://hg.mozilla.org/mozilla-central/rev/e599fad2ef50
| Assignee | ||
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Description
•