Open Bug 1872858 Opened 6 months ago Updated 8 days ago

Webgpu demo freezes browser UI and if you open about:support, it is blank

Categories

(Core :: Graphics: WebGPU, defect)

defect

Tracking

()

REOPENED
Tracking Status
firefox-esr115 --- unaffected
firefox121 --- disabled
firefox122 --- disabled
firefox123 --- disabled
firefox124 --- disabled

People

(Reporter: mayankleoboy1, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug, Regression, )

Details

(Keywords: regression)

Crash Data

Attachments

(5 files, 1 obsolete file)

Use latest Nightly on Windows
Go to https://yuu6883.github.io////WebGPUDemo/?cloth
Try resizing the browser window
OR, open about:support

AR: Browser UI freezes . If you open about:support, then the rows are blank

Regresion range :

Bug 1859999 - Update wgpu to revision 75989192a9c8f70893882ce0f4373ac217d380c3. r=webgpu-reviewers,supply-chain-reviewers,nical

Differential Revision: https://phabricator.services.mozilla.com/D191400

Attached file about:support
Attached image bug.png

Empty about:support

See Also: → 1852492

gfx+webgpu logs

Set release status flags based on info from the regressing bug 1859999

:teoxoy, since you are the author of the regressor, bug 1859999, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(ttanasoaia)
Severity: -- → S3

I tried reproducing the blank about:support but it worked for me, could someone else also try?

The regressor is the wgpu update that brought in const-expression support which is the functionality that was blocking the example from working.
It now fails later with a different error but doesn't cause the browser to freeze when resized.

The example does take a long time to start.

Flags: needinfo?(ttanasoaia)
Crash Signature: [@ wgpu_bindings::server::wgpu_server_texture_destroy ] [@ mozilla::webgpu::Texture::Texture ]

If I disable remote canvas, subjectively it feels much better.. There is no UI hang etc.

https://share.firefox.dev/48mbAMO

The symptoms seem to hint at the recent canvas-y changes.

Lee, any sense of off-main-thread impact here?

Flags: needinfo?(lsalzman)

No idea, my changes would not touch webgpu.

Flags: needinfo?(lsalzman)

moar logging

See Also: → 1874597

Set release status flags based on info from the regressing bug 1859999

:nical: Is the second crash link from Mayank maybe related to the eager texture destruction issue you filed at gfx-rs/wgpu#5079?

Flags: needinfo?(nical.bugzilla)

The issue I filed is about internal hal resource lifetime whereas this crash is happening one level above, in the registry.
The ID is invalid. That suggests that somehow IPC messages are dropped or reordered or that we are trying to reuse an ID from before a GPU process crash after we re-create it.

About the original issue, it looks like shaders are taking forever to compile (presumably FXC's known struggles), which blocks the canvas renderer thread. Since remote canvas also uses the canvas renderer thread, it's likely that the compositor is waiting for that the remote canvas work to finish but the latter is blocked until the shader is compiled as collateral damage from being on the same thread as WebGPU.

Flags: needinfo?(nical.bugzilla)

I see similar issue on other WebGPU demo like : https://martinlaxenaire.github.io/gpu-curtains/

See Also: 18745971878449
Attachment #9387756 - Attachment is obsolete: true

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 10 days ago
Resolution: --- → WORKSFORME

This bug is not about crashes, but about hangs.
I can still repro the blank about:support

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: