1887287 - Closing webgpu demos doesnt release memory, making testing webgpu on Nightly very difficult

Status: RESOLVED FIXED

(Core :: Graphics: WebGPU, defect, P1)

Description

[Mayank Bansal]

This started about a 1-1.5 months ago and occurred after a wgpu update/sync (I dont remember which wgou update though). I didnt file a bug as I thought someone will notice this and fix it, but this is still not fixed.

STR are very simple:

STR1

1. Go to https://webgpu.github.io/webgpu-samples/?sample=helloTriangle
2. Using the middle-mouse button, open the first demo in 7-8 background tabs

STR2

1. Open any webgpu demo like https://webgpu.github.io/webgpu-samples/?sample=helloTriangle
2. Reload the page using the reload button a 8-9 times
   (Edit: This particularly STR2 may be an older problem)

AR: The memory steadily keeps on increasing at each reload. Memory doesnt reduce even if you close the tab. The end result is that after testing 3-4 demos (or 3-4 reloads of 1 demo), the browser becomes unstable or crashes etc.
ER: The memory shouldnt increase so drastically. Memory should go back to Baseline when the demo tab is closed.

Comment 1

[Mayank Bansal]

Profile with webgpu preset logging : https://share.firefox.dev/3TwjMnr
Profile with JS and native allocations: https://share.firefox.dev/4a0jf4i

Comment 2

[Mayank Bansal]

Attachment: memory-report.json.gz

look at PID-16368

Comment 3

[Mayank Bansal]

Attachment: about:support

Comment 4

[Mayank Bansal]

This may have started with bug 1876389 or bug 1879989,

Comment 5

[Erich Gubler [:ErichDonGubler]]

Observations while reproducing on my Windows 11 machine:

• Initial memory usage seems to start out relatively high on initial page load, climbing to ~170 MB on the content process.
• Using the same single tab from the last observation, I'm able to refresh constantly and achieve a peak of ~325 MB of memory usage for a single content process using WebGPU on https://webgpu.github.io/webgpu-samples/?sample=helloTriangle. I am unable to push the tab to allocate further than this. Within 15-20 seconds, memory returns to its stable baseline of ~115MB.
• Now, the interesting part that's relevant to the OP: the GPU process accumulates gigabytes of memory in less than ten seconds. This memory was not released until the process was ended, despite forced GC and CC runs in about:memory.

I assume that all the content process' JS objects are being cycle-cleaned, so my hypotheseses for root cause are:

1. We're not correctly cleaning up resources internally in wgpu-core. This is unfortunately likely, since we've recently reworked the internals of resource tracking, and are still finding bugs. CC :nical.
2. Something was always broken in our plumbing of clean-up of WGPU resources between JS objects and wgpu-core's resource handles.

Given Mayank's note about this regressing with a specific re-vendoring of WGPU, I think (1) is more likely. Triaging as a P1, since this is likely to hamper the WebGPU team's ability to debug things, and related to the OOMS we experience in CI.

Comment 6

[Mayank Bansal]

This issue is still present on the latest Nightly.

Comment 7

[Mayank Bansal]

This is a LOT better now. I did a bisection, and it points to bug 1906679. Out of curiosity, do we know which change fixed this memory bug? (Edit: Looks to be https://github.com/gfx-rs/wgpu/pull/5910)

ttanasoaia : Up to you if you want to keep this bug open for any additional investigation. I am OK to close this bug as fixed by bug 1906679.

Comment 8

[Teodor Tanasoaia [:teoxoy]]

That's good to hear! So the memory usage is a lot lower but we are still leaking somewhere? If the answer is yes, let's keep it open and I will take a look sometime this half.

Comment 9

[Mayank Bansal]

The original STR has been fixed since comment #7. I will close this bug.