1880005 - [WebGPU] with dx12-no-readback enabled, browser hangs, flashes white and falls back to sw-wr on https://codepen.io/search/pens?q=webgpu

Status: VERIFIED FIXED

(Core :: Graphics: WebGPU, defect)

Description

[Mayank Bansal]

0. Use latest Nightly (enable webgpu and the dx12-no-readback thingy)
1. Login to codepen
2. Go to https://codepen.io/search/pens?q=webgpu
3. Wait for the page to load completely. Codepen should load the assets of all the 6 demos in the background.
   At this stage the tab would use 1GB+ memory
   3.5 Maybe try hovering mouse over one of the demos so that it starts playing.
4. Try clicking on one of the dropdowns - "sort by" or "search depth" , or try clicking on UI element of the browser

AR: The browser freezes. It eventually flashes white and falls back to sw-wr
ER: Not so

This may just be a case of too many webgpu things in a single tab.

Comment 1

[Mayank Bansal]

Attachment: about:support after fallback to sw-wr

Comment 2

[Mayank Bansal]

Attachment: GOOD_log.txt-main.864.moz_log

"Good" log.
dx-12-no-readback thingy is disabled.
Page behaves as expected with no hang/crash.

Comment 3

[Mayank Bansal]

Attachment: BAD_log.txt-main.1808.moz_log

"Bad" log.
dx12-no-readback is ENABLED.
Page froze, the whole browser froze for some time. Then it flashed whit, and fallback to sw-wr.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 5

[Mayank Bansal]

I dont think there is anything special about the page https://codepen.io/search/pens?q=webgpu ....
If you open a simple demo like https://webgpu.github.io/webgpu-samples/samples/helloTriangle on 6 different tabs, you get similar bug.

Comment 6

[Sotaro Ikeda [:sotaro]]

When the problem happened, Renderer thread was blocked at Renderer11::flush(Context11 *context11) that was called under Renderer::draw_frame()

CanvasRender thread was blocked at device->CreateTexture2D() in ExternalTextureD3D11::GetSnapshot() or ExternalTextureD3D11::Create().

Further, there was a case that when Renderer thread was blocked at Renderer11::flush(Context11 *context11), CanvasRender thread was not blocked.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 8

[Sotaro Ikeda [:sotaro]]

context4->Wait(fence, mFenceValue) in FenceD3D11::Wait() seemed to trigger the hang at ID3D11DeviceContext::Flush()

Comment 9

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1880005 - Fix FenceHandle handling in WebGPUParent

Comment 10

[Sotaro Ikeda [:sotaro]]

FenceHandle handling in WebGPUParent was wrong. The FenceHandle exists for each device.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/66928be3e7e7
Fix FenceHandle handling in WebGPUParent r=lsalzman

Comment 12

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/66928be3e7e7

Comment 13

[Mayank Bansal]

This is fixed in the latest Nightly.