Warn in console when `GPUDevice.createShaderModule` fails
Categories
(Core :: Graphics: WebGPU, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox114 | --- | fixed |
People
(Reporter: jgilbert, Assigned: ErichDonGubler, Mentored)
References
Details
Attachments
(6 files, 5 obsolete files)
This is optional, but is really nice and we should have it.
| Reporter | ||
Updated•3 years ago
|
| Reporter | ||
Comment 1•3 years ago
|
||
Erich expressed interest in implementing this, so I'll just assign it so no one else picks it up in the meantime.
| Assignee | ||
Comment 2•3 years ago
|
||
This sort of functionality is called for in the current draft of section 9.1.1 of the WebGPU v1 spec. ("Shader Module Creation"), more specifically the createrShaderModule(descriptor) item's note on "Device timeline initialization steps":
Note: User agents should not include detailed compiler error messages or shader text in the
messagetext of validation errors arising here: these details are accessible viagetCompilationInfo(). User agents should surface human-readable, formatted error details to developers for easier debugging (for example as a warning in the browser developer console, expandable to show full shader source).As shader compilation errors should be rare in production applications, user agents could choose to surface them to developers regardless of error handling (GPU error scopes or
uncapturederrorevent handlers), e.g. as an expandable warning. If not, they should provide and document another way for developers to access human-readable error details, for example by adding a checkbox to show errors unconditionally, or by showing human-readable details when logging aGPUCompilationInfoobject to the console.
| Assignee | ||
Comment 3•3 years ago
|
||
:jgilbert also mentioned that we have some precedent for this behavior in WebGL at WebGLProgram.cpp:924-937.
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 4•3 years ago
|
||
Attaching an HTML file with an embedded JS script that creates and reports to the dev. console from GPUShaderModule.compilationInfo. This basically implements the easy-to-implement behavior I think we should have for this ticket, subject to feedback from :jimb.
| Assignee | ||
Comment 5•3 years ago
|
||
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 6•3 years ago
|
||
This attachment describes behavior close to what :jimb has requested in our conversation in internal Matrix chat for WebGPU. The only thing it doesn't do is print only the first line of the first error or warning in the "sentinel" message printed before the collapsed console message group.
| Assignee | ||
Comment 7•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
| Reporter | ||
Comment 8•3 years ago
|
||
(In reply to Erich Gubler [:ErichDonGubler] from comment #2)
This sort of functionality is called for in the current draft of section 9.1.1 of the WebGPU v1 spec. ("Shader Module Creation"), more specifically the
createrShaderModule(descriptor)item's note on "Device timeline initialization steps":
Not that this is a bad idea per se, but we aren't compelled by it. This was written by companies other than us and merged without collaboration. We should (on our own) pick what we think is best.
Updated•3 years ago
|
| Assignee | ||
Comment 9•3 years ago
|
||
Refine the console group title for shader compilation messages by adding aggregated counts of each message by type.
Depends on D175303
| Assignee | ||
Comment 10•3 years ago
|
||
This results in lukewarm gains at best for the code that currently exists, but subsequent patches in this stack will look much better for it. So do it now.
Depends on D175402
| Assignee | ||
Comment 11•3 years ago
|
||
@jimb expressed concern that a collapsed group of compilation messages for WebGPU shaders in the JS console isn't easy enough to discern from scanning a console log manually. We can't associate a log level with the group itself (which would let us paint the group with color for contrast), unfortunately. So, we decided to have a "sentinel" message right before groups that uses the highest "severity" of message in the entire set of compilation messages.
Depends on D175403
| Assignee | ||
Comment 12•3 years ago
|
||
We don't set the GPUObjectBase.label of the shaderModule we create in our implementation of GPUDevice.createShaderModule, but we should. Fix it! You can see this reflected in the error diagnostics currently returned by Naga in the GPUCompilationMessage.message field.
Depends on D175404
| Assignee | ||
Comment 13•3 years ago
|
||
This context is crucial for debugging, kthxbai.
Depends on D175405
| Assignee | ||
Comment 14•3 years ago
|
||
Adding a new test file that (1) demonstrates the behavior that was prototyped, as before, and (2) exercises cases where the GPUObjectDescriptorBase.label for GPUShaderModuleDescriptor is omitted and specified.
| Assignee | ||
Comment 15•3 years ago
|
||
Depends on D175406
Updated•3 years ago
|
Updated•3 years ago
|
Comment 16•3 years ago
|
||
Comment 17•3 years ago
|
||
Backed out for causing build bustages in WebGPUChild.cpp/Device.cpp
- Backout link
- Push with failures
- Failure Log
- Failure line: /builds/worker/checkouts/gecko/dom/webgpu/ipc/WebGPUChild.cpp:817:10: error: call to member function 'AppendInt' is ambiguous
/builds/worker/checkouts/gecko/dom/webgpu/Device.cpp:195:10: error: arguments must all be strong refs or caller's parameters when calling a function marked as MOZ_CAN_RUN_SCRIPT (including the implicit object argument). 'mBridge->' is neither.
| Assignee | ||
Updated•3 years ago
|
Comment 18•3 years ago
|
||
Comment 19•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/b4ddc5f8bf51
https://hg.mozilla.org/mozilla-central/rev/627cbf1749d5
https://hg.mozilla.org/mozilla-central/rev/3db3f3df4f44
https://hg.mozilla.org/mozilla-central/rev/8aca8c275beb
https://hg.mozilla.org/mozilla-central/rev/5e7c8062bed4
Description
•