Automatic pipeline layout
Categories
(Core :: Graphics: WebGPU, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox111 | --- | unaffected |
firefox112 | --- | unaffected |
firefox113 | --- | disabled |
firefox114 | --- | fixed |
People
(Reporter: jimb, Assigned: jimb)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [webgpu-cts-fail])
Attachments
(2 files)
The WebGPU spec says:
enum GPUAutoLayoutMode {
"auto"
};
dictionary GPUPipelineDescriptorBase : GPUObjectDescriptorBase {
required (GPUPipelineLayout or GPUAutoLayoutMode) layout;
};
but Mozilla Central's dom/webidl/WebGPU.webidl
says:
dictionary GPUPipelineDescriptorBase : GPUObjectDescriptorBase {
GPUPipelineLayout layout;
};
This leads to WebGPU CTS failures like:
assert_unreached: - EXCEPTION: GPUDevice.createComputePipeline: 'layout' member of GPUPipelineDescriptorBase is not an object. testAdapter@https://web-platform.test:8443/_mozilla/webgpu/webgpu/api/operation/adapter/requestAdapter.spec.js:35:27 Reached unreachable code
wpt_fn@https://web-platform.test:8443/_mozilla/webgpu/common/runtime/wpt.js:65:25
Assignee | ||
Updated•2 years ago
|
Comment 2•2 years ago
|
||
The following field has been copied from a duplicate bug:
Field | Value | Source |
---|---|---|
Regressed by | bug 1720941 | bug 1814090 |
For more information, please visit auto_nag documentation.
Comment 3•2 years ago
|
||
:ErichDonGubler, since you are the author of the regressor, bug 1720941, could you take a look?
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
Yes, this is just a restatement of that bug with a better description.
Assignee | ||
Comment 5•2 years ago
|
||
Easiest way to reproduce:
-
Make sure that
testing/web-platform/mozilla/meta/webgpu/__dir__.ini
doesn't have adisabled:
property that causes all tests to be skipped. -
Edit
testing/web-platform/mozilla/tests/webgpu/chunked/1/cts.https.html
and remove all but the following<meta>
element (the first, at the moment):<meta name=variant content='?q=webgpu:api,operation,adapter,requestAdapter:requestAdapter:*'>
-
In the shell:
$ ./mach wpt /_mozilla/webgpu/chunked/1
Comment 6•2 years ago
|
||
:jimb: WPT pro tip: You can also paste the variant query params (the content of the, err, content
attribute) as part of the URL; meaning, your above repro steps can also be simplified to:
- Make sure that
testing/web-platform/mozilla/meta/webgpu/__dir__.ini
doesn't have adisabled:
property that causes all tests to be skipped. - Run
./mach wpt '/_mozilla/webgpu/chunked/1/cts.https.html?q=webgpu:api,operation,adapter,requestAdapter:requestAdapter:*'
It can be even faster to use the repro link in the bug I originally filed (1814090), which uses this URL to use the latest upstream of the test: https://gpuweb.github.io/cts/standalone/?runnow=1&q=webgpu%3Aapi%2Coperation%2Ccompute_pipeline%2C*. WebGPU CTS' current documentation/culture strongly encourages the use of its standalone testing for debugging. However, I do consider it important to have instructions to reliably reproduce a failure given a Mercurial revision, so this would be a strictly additive suggestion.
Comment 7•2 years ago
|
||
Set release status flags based on info from the regressing bug 1720941
Assignee | ||
Comment 8•2 years ago
|
||
Adapt WebGPU.webidl for gpuweb#2657, which changed the way to request automatic pipeline layout: rather than simply omitting the layout
property from the pipeline descriptor, you now need to say layout: "auto"
.
Assignee | ||
Comment 9•2 years ago
|
||
The change causes around ~5000 unexpected passes in the WebGPU CTS, so the expectations need to be updated. Just attaching the CTS output for the record - it took 45min to run, so I don't want to have to recreate it.
Assignee | ||
Comment 10•2 years ago
|
||
The change causes around ~5000 unexpected passes in the WebGPU CTS
It turns out most of these were due to differences between my machine (on which WebGPU does well) and the CI machines (on which it does less well).
New try push, which will produce new expectation data for the CI machines as an artifact:
https://treeherder.mozilla.org/jobs?repo=try&revision=589a0d0bec824ad5b9a2a8420b3f534f76f43099
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 11•2 years ago
|
||
That try push didn't run any WebGPU web platform tests. :(
New mach try fuzzy push with query 'web-platform-tests !tsan !asan !macos !android:
https://treeherder.mozilla.org/jobs?repo=try&revision=04af64441b0806d1fd02657df6c8b71eac5445b4
Assignee | ||
Comment 12•2 years ago
|
||
That try push doesn't show any unexpected passes, as far as I can tell, so I'm just going to proceed with landing this and see how it goes.
Comment 15•2 years ago
|
||
I don't think it makes sense to keep this bug as a dependency of webgpu-v1
, since it's also a dependency of webgpu-v1-cts-blockers
and no-webgpu-samples-shim
. Removing blocking relationship to webgpu-v1
.
Comment 16•2 years ago
|
||
Comment 17•2 years ago
|
||
bugherder |
Comment 18•2 years ago
|
||
The patch landed in nightly and beta is affected.
:jimb, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox113
towontfix
.
For more information, please visit auto_nag documentation.
Comment 19•2 years ago
|
||
This shouldn't be in beta at all; just nightly. I don't think uplifting makes sense, and feel confident enough to make this call before :jimb starts his work day. I'll pick fix-optional
, to be consistent with firefox113
's field.
Updated•2 years ago
|
Assignee | ||
Comment 20•2 years ago
|
||
Yes - WebGPU is disabled on beta at several levels.
Assignee | ||
Updated•2 years ago
|
Comment 21•2 years ago
|
||
marking 114 (nightly) back as fixed, since it already landed in 114 in https://bugzilla.mozilla.org/show_bug.cgi?id=1821219#c17
marking 113 (beta) as disabled since WebGPU is disabled in beta
Description
•