Remove MacOS from WebGPU blocklist
Categories
(Core :: Graphics: WebGPU, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox130 | --- | fixed |
People
(Reporter: ErichDonGubler, Assigned: ErichDonGubler)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 6 obsolete files)
From WebGPU team chat on 2023-11-14:
ErichDonGubler: [In an experiment I did recently (
try:a0e6d9c553c1
),] MacOS tests ranchunked
tests in a single chunk in <50m … . That (a) doesn't sound like we're doing much there, eek things broken, and (b) makes our current chunk configuration feel really wasteful. Observe thatwebgpu9
runs allwebgpu/cts/chunked
tests, andwebgpu10
runs allwebgpu/cts/webgpu
tests.
:jimb: Yeah, and every test seems to take a consistent ~600ms. Very suspicious.
:ErichDonGubler: I'd wager that's how long it takes each test to get to trying to use navigator.gpu, or something close and early in the common API sequence to do things? 😅
:jimb: Yeah, probably.
:jimb: I'll bet they're all hitting the blocklist
Comment 1•11 months ago
|
||
If it is indeed the blocklist, then we can employ the gfx.webgpu.ignore-blocklist
pref.
Comment 2•11 months ago
|
||
(In reply to Jim Blandy :jimb from comment #1)
If it is indeed the blocklist, then we can employ the
gfx.webgpu.ignore-blocklist
pref.
We've already set this pref for webgpu mochitests.
Assignee | ||
Comment 3•11 months ago
|
||
Assignee | ||
Comment 4•11 months ago
|
||
Updated•11 months ago
|
Updated•11 months ago
|
Assignee | ||
Comment 5•11 months ago
|
||
Assignee | ||
Updated•11 months ago
|
Updated•11 months ago
|
Updated•11 months ago
|
Assignee | ||
Comment 7•11 months ago
•
|
||
Status update: quoting this comment in D193612:
Hmmm…the latest Try push I've submitted with D193682 included (try:440344eacf9b) has not worked as I'd hoped. The decision to initialize WebGPU does not seem like something we can easily live-update with current code. Trying to change this seems to entail a bunch of design decisions that are a distraction from the core of this problem, which is that we expect hardware that supports MacOS 10.15 to be compatible with WebGPU, and not blocklisted[^1].
I'd prefer to explore other options like fixing our blocklist before going further down this hacky path. Abandoning for now.
[^1]: Examples: How do we transition currently open tabs when this preference changes?
:jimb, I think we simply need to focus on fixing the blocklist, but this is not something I have experience with. NI'ing you for help here, since I think it shouldn't be a huge lift.
Will un-assign this bug from myself once the test expectations patch I landed in autoland
makes it to central
.
Assignee | ||
Updated•11 months ago
|
Comment 8•11 months ago
|
||
bugherder |
Assignee | ||
Updated•11 months ago
|
Assignee | ||
Updated•11 months ago
|
Updated•11 months ago
|
Assignee | ||
Updated•9 months ago
|
Assignee | ||
Updated•9 months ago
|
Assignee | ||
Updated•9 months ago
|
Comment 9•9 months ago
|
||
I don't know much about the blocklist code either, unfortunately. Happy to pair on this if you like.
Assignee | ||
Comment 10•9 months ago
•
|
||
Currently blocked on gfx-rs/wgpu
#2432. Without it, we shouldn't consider exposing any users to the unsafety with vertex attribute data. We have a blocklist entry that we want corresponding to it at widget/cocoa/GfxInfo.mm
:478-482:
// wgpu doesn't safely support OOB behavior on Metal yet.
IMPLEMENT_MAC_DRIVER_BLOCKLIST(
OperatingSystem::OSX, DeviceFamily::All, nsIGfxInfo::FEATURE_WEBGPU,
nsIGfxInfo::FEATURE_BLOCKED_DEVICE,
"FEATURE_FAILURE_MAC_WGPU_NO_METAL_BOUNDS_CHECKS");
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Assignee | ||
Comment 15•9 months ago
|
||
D'oh, I erroneously filed the above patches against this bug, instead of bug 1873696. Sorry for the noise!
Comment 16•9 months ago
|
||
Comment on attachment 9371923 [details]
WIP: Bug 1864698: test(webgpu): prep. refac. for second approx. of CTS test splitting r=#webgpu-reviewers!
Revision D198120 was moved to bug 1873696. Setting attachment 9371923 [details] to obsolete.
Comment 17•9 months ago
|
||
Comment on attachment 9371924 [details]
WIP: Bug 1864698: test(webgpu): make CTS case splitting logic determine WPT timeout len. r=#webgpu-reviewers!
Revision D198121 was moved to bug 1873696. Setting attachment 9371924 [details] to obsolete.
Comment 18•9 months ago
|
||
Comment on attachment 9371925 [details]
WIP: Bug 1864698: test(webgpu): make …:device_lost:destroy
CTS cases use short WPT timeout r=#webgpu-reviewers!
Revision D198122 was moved to bug 1873696. Setting attachment 9371925 [details] to obsolete.
Comment 19•9 months ago
|
||
Comment on attachment 9371926 [details]
WIP: Bug 1864698: test(webgpu): adjust vendored CTS file perms. to match upstream for Unix platforms r=#webgpu-reviewers!
Revision D198123 was moved to bug 1873696. Setting attachment 9371926 [details] to obsolete.
Assignee | ||
Comment 20•9 months ago
|
||
TODO: Validate that this is actually safe to do, per the comment being
removed. @ErichDonGubler has asked here:
https://matrix.to/#/!AQDMTeppDxxlzBSBzM:mozilla.org/$JO9ErjRjlLAGKGHAZOJz8K0Md3fB1_63z3Yhd5pLQqo?via=mozilla.org
Assignee | ||
Updated•8 months ago
|
Comment 21•8 months ago
|
||
WebGPU is unreleased tech. Dropping Severity to S3 to remove from org tracking.
Updated•6 months ago
|
Comment 22•3 months ago
|
||
Since https://github.com/gfx-rs/wgpu/issues/2432 is now resolved and the changes pulled into Firefox can macOS be un-blacklisted?
Updated•3 months ago
|
Comment 23•3 months ago
|
||
I just verified that we are requesting Naga-injected bounds checking on other indexing operations, so yeah, indexed draw calls were the last step. I'm not aware of any reason to keep this blocklisted in nightly.
Comment 24•3 months ago
|
||
Comment 25•3 months ago
|
||
Comment 26•3 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/bb79dcf0336e
https://hg.mozilla.org/mozilla-central/rev/e5b11a4833d1
Assignee | ||
Comment 27•2 months ago
|
||
I'd forgotten to remove the CI configuration that worked around the thing this bug fixes. Catching up with that in bug 1909265.
Description
•