1880625 - [GPU-Canvas] continuous memory increase on multiple demo pages

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[Mayank Bansal]

1. Use latest Nightly on windows
2. Set the following prefs

gfx.direct2d.disabled = true
gfx.canvas.accelerated = true
gfx.canvas.remote.worker-threads = 0

Go to https://codepen.io/KilledByAPixel/pen/OJqaRjR

AR: Continuous memory increase, performance is also not that good. The good thing is that as soon as you put the demo in background, the memory is released immediately.
ER: Great perf, no memory increase

gpu-canvas(good, 1Oct2023): https://share.firefox.dev/3I2ik77
gpu-canvas (bad,16Feb2024): https://share.firefox.dev/3SZYMq6
d2d-canvas: https://share.firefox.dev/3T0DIji
skia-canvas: https://share.firefox.dev/3I3LuTo

Regressed by :

Bug 1829026 - Handle KERN_ABORTED from semaphore_wait. r=aosmond
Differential Revision: https://phabricator.services.mozilla.com/D195952

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Mayank Bansal]

Attachment: memory-report.json.gz

Look at the GPU process. It takes 4gb+

Comment 3

[Mayank Bansal]

Attachment: standalone_testcase.html

Comment 4

[Mayank Bansal]

Other pages with extremely rapid memory growth (open the page, set zoom to 30%, reload the page)
https://js1k.com/2016-elemental/demo/2497
https://js1k.com/2013-spring/demo/1390

Profile: https://share.firefox.dev/48kjipO , https://share.firefox.dev/3T2vG9y

Comment 5

[Lee Salzman [:lsalzman]]

Actually, n'm that idea. It seems like I misinterpreted the pref, which is actually 32KB buffer size, not 32MB size, so something else must be temporarily eating up a lot of memory, though still limited by something.

Comment 6

[Mayank Bansal]

Profile with memory tracking if it helps : https://share.firefox.dev/3I4op36

Comment 7

[Lee Salzman [:lsalzman]]

That does help, yes. It looks like RemoteTextureMap is just hanging on to a lot of buffers temporarily. It doesn't quite answer where they are all going, though. Sotaro, do you have an idea of what may be causing RemoteTextureMap to be having many GB of in-flight TextureDatas?

I don't think it's the buffer recycling bin, because if you imagine a 4K screen making buffers 384021604bpp, those buffers use about 32MB, and then 21 (current hard-coded limit) of them only uses 672MB. So there are either waiting buffers, or buffers being used, accumulating somewhere in RemoteTextureMap, somewhere, somehow?

Comment 8

[Mayank Bansal]

And a profile with graphics preset logging: https://share.firefox.dev/3wlV7KA

Comment 9

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

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

Comment 10

[Sotaro Ikeda [:sotaro]]

When the problem happened, Runnable in RemoteTextureMap::KeepTextureDataAliveForTextureHostIfNecessary() was not called. I wonder if Canvas render thread was too busy by already queued tasks.

And ImageBridgeChild::GetSingleton() in DrawTargetWebgl::CopyToSwapChain() does not work in GPU process. Then it always forces readback to MemoryTextureData.

Comment 11

[Mayank Bansal]

With the latest Nightly, there is a slight change in the memory use pattern for the attached testcase (and https://js1k.com/2016-elemental/demo/2497) : The memory still grows continuously, but now in Task Manager it appears as the "system-level" memory increase and not attributed to any firefox process.

Profile: https://share.firefox.dev/49nPZEp (no memory increase at first, and then steady rise)

For the demo https://js1k.com/2013-spring/demo/1390 , the memory increase is rapid and occurs at the firefox process level.

Comment 12

[Mayank Bansal]

Attachment: memory-report.json.gz

Memory report from Nightly (https://hg.mozilla.org/mozilla-central/rev/2e4867d8cc9813869bd80f5201d3f7d84afcd412) .
When this report was generated the "system-level" memory was ~8.4GB (from a baseline of ~4.7GB) but none of the Firefox processes were taking more than 200-400MB RAM.

Comment 13

[Lee Salzman [:lsalzman]]

(In reply to Sotaro Ikeda [:sotaro] from comment #10)

When the problem happened, Runnable in RemoteTextureMap::KeepTextureDataAliveForTextureHostIfNecessary() was not called. I wonder if Canvas render thread was too busy by already queued tasks.

And ImageBridgeChild::GetSingleton() in DrawTargetWebgl::CopyToSwapChain() does not work in GPU process. Then it always forces readback to MemoryTextureData.

In that check for NumCompositableRefs() >= 0, is that even correct? That will always be true. Did you mean > 0?

Comment 14

[Sotaro Ikeda [:sotaro]]

(In reply to Lee Salzman [:lsalzman] from comment #13)

(In reply to Sotaro Ikeda [:sotaro] from comment #10)

When the problem happened, Runnable in RemoteTextureMap::KeepTextureDataAliveForTextureHostIfNecessary() was not called. I wonder if Canvas render thread was too busy by already queued tasks.

And ImageBridgeChild::GetSingleton() in DrawTargetWebgl::CopyToSwapChain() does not work in GPU process. Then it always forces readback to MemoryTextureData.

In that check for NumCompositableRefs() >= 0, is that even correct? That will always be true. Did you mean > 0?

Yes, it should be "> 0". That part is changed to "> 0" by Bug 1872087.