`WebGPU is disabled by blocklist` in Windows CI
Categories
(Core :: Graphics: WebGPU, defect, P1)
Tracking
()
People
(Reporter: ErichDonGubler, Assigned: ErichDonGubler)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
Attachments
(1 obsolete file)
There appears to be an odd variance in Windows CI environments where WebGPU does not run, and the diagnostic emitted blames our blocklist:
EXCEPTION: WebGPU device failed to initialize with NotSupportedError "WebGPU is disabled by blocklist."; not retrying
When this error is encountered, all WebGPU CTS tests in the job fail. EDIT: Actually, it appears that test runs can recover from this. 🤔⁉️
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (obsolete) |
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
Updated•1 year ago
|
Comment 6•1 year ago
•
|
||
Raising the priority on this to P1: "CTS impact widespread enough that it obscures other issues", based on Matrix discussion with EDG.
Leaving the severity as S3, per WebGPU project policy.
| Assignee | ||
Comment 8•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 9•1 year ago
|
||
Not sure that I have a strong lead on resolving this yet, but I did want to note an interesting observation: It appears we may legitimately have different graphics adapters. In most cases (where this issue isn't happening), a log message is occasionally printed by glean with the following text:
[WARN glean_core::error_recording] gfx.adapter.primary.driver_files: Value length 811 exceeds maximum of 100
However, in tests that do run into this issue, there is no such thing, implying that the set of driver files is small enough to fit within the limit.
Comment 10•1 year ago
|
||
One way to debug this would be to start with that error message:
EXCEPTION: WebGPU device failed to initialize with NotSupportedError "WebGPU is disabled by blocklist."; not retrying
and then work backwards to find the sufficient conditions for getting that message, and add logging at each point so we can see in detail how we're arriving at that message. For example, it sure would be nice to know which blocklist entry we're hitting.
This would entail repeated submissions to the try server, so it would need to be a background project.
| Comment hidden (Intermittent Failures Robot) |
Updated•1 year ago
|
| Assignee | ||
Comment 12•1 year ago
|
||
A patch stack now exists against dependency bug 1899536. Once it's landed, this should be resolved. 🙌🏻
| Assignee | ||
Updated•1 year ago
|
| Comment hidden (Intermittent Failures Robot) |
| Assignee | ||
Updated•1 year ago
|
Description
•