1945997 - 1GB of heap-unclassified in gpu-process on AWFY

Status: RESOLVED FIXED

(Core :: Graphics, enhancement)

Description

[Mayank Bansal]

Go to https://arewefastyet.com/win11/benchmarks/raptor-desktop-jetstream2?numDays=60&series=Firefox
Let it reload
Reload it a few more times
open about:memory and measure verbose

AR:

1,239,569,232 B (100.0%) -- explicit
├────958,409,776 B (77.32%) ── heap-unclassified
├────267,236,832 B (21.56%) -- gfx
│ ├──267,236,832 B (21.56%) -- webrender
│ │ ├──234,606,816 B (18.93%) ── swgl
│ │ ├───13,066,240 B (01.05%) -- resource-cache
│ │ │ ├──13,066,240 B (01.05%) ── fonts
│ │ │ ├───────────0 B (00.00%) ── images
│ │ │ ├───────────0 B (00.00%) ── rasterized-blobs
│ │ │ └───────────0 B (00.00%) ── weak-fonts
│ │ ├────7,340,032 B (00.59%) ── upload-stagin-memory
│ │ ├────7,115,664 B (00.57%) ── texture-cache/structures

Not sure if this is expected after bug 1926970 has been fixed?

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Mayank Bansal]

Attachment: memory-report.json.gz

Comment 3

[Lee Salzman [:lsalzman]]

I am having trouble reproducing this. Could you try producing a DMD report that might show where all the heap-unclassified is coming from?

See: https://firefox-source-docs.mozilla.org/performance/memory/dmd.html

Comment 4

[Mayank Bansal]

Attachment: Temp.7z

Comment 5

[Lee Salzman [:lsalzman]]

Can you then run dmd.py on the main and gpu process json files for me to generate the reports?

Comment 6

[Lee Salzman [:lsalzman]]

A profiler run too would also be helpful, looking at the individual DMD reports, it's not obvious which one is the GPU process and I am not seeing any huge numbers in there that would correspond the the heap-unclassified.

Comment 7

[Mayank Bansal]

i have no idea how to run .py files. I am trying to install python from windows Store. What version of python should i install?

Comment 8

[Mayank Bansal]

this is the error i get when i drag-drop the file in the python cli:

"C:\Users\mayan\OneDrive\Desktop\New folder\dmd.py"
File "<stdin>", line 1
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 2-3: truncated \UXXXXXXXX escape

Comment 9

[Mayank Bansal]

If you cant repro, maybe try opening the link in two tabs, then apply filter on the two tabs from the UI of the page (which will cause the page to redraw all the graphs).

Comment 10

[Mayank Bansal]

Attachment: dmd-1738845634-11008.json.gz - GPU-process

Comment 11

[Mayank Bansal]

Attachment: dmd-1738845634-4228.json.gz - main-process

main-process: PID=4228

Comment 12

[Mayank Bansal]

Attachment: memory-report.json.gz

GPU-process: pid=11008
main-process: PID=4228

Comment 13

[Mayank Bansal]

Do the dmd reports for the main process and gpu process help?

Comment 14

[Lee Salzman [:lsalzman]]

The reports don't show any large chunks of memory being allocated like what you're seeing, so I'm a bit stumped.

Comment 15

[Lee Salzman [:lsalzman]]

Also it doesn't seem like I can get proper symbolified stacks from these running the dmd.py script on them myself, so it would help if that could be done on your end. Even so, there is still no 1GB of memory showing up in the report.

Comment 16

[Mayank Bansal]

the heap-unclassified happens after you open 5-6 tabs with large graphs and then reload all the tabs a few times or apply filters a few times. Then the heap-unclassified shows up.

Comment 17

[Lee Salzman [:lsalzman]]

(In reply to Mayank Bansal from comment #16)

the heap-unclassified happens after you open 5-6 tabs with large graphs and then reload all the tabs a few times or apply filters a few times. Then the heap-unclassified shows up.

I have tried, and I can't get it to do that, no matter what. It will show up a lot under heap-textures, but reported, and not heap-unclassified. It would really help if you can get a symbolified memory report via dmd.py that shows some sort of record of where this memory is coming from.

Comment 18

[Lee Salzman [:lsalzman]]

I am still having trouble reproducing, but as much as I can see, there seems to be something very weird going on with WebRender here, creating a bunch of SWGL textures, so I am not sure any of these overheads are actually coming from Canvas2D.

Comment 19

[Lee Salzman [:lsalzman]]

Attachment: Bug 1945997 - Ensure common memory reporters get registered in GPU process. r?ahale

gfxPlatform::Init() is never called in the GPU process, so common memory reporters
never get registered, such as GfxImageMemoryReporter, leading to large amounts of
heap-unclassified showing up in the GPU process when using Accelerated Canvas2D.

For now, add a gfxPlatform::InitMemoryReportersForGPUProcess() hook for any such
registration to occur in the GPU process. Long-term, we probably should clean up
gfxPlatform::Init() to share far more code with GPUParent::Init/RecvInit, but that
is a much larger project beyond the scope of this patch.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5c62ffef25ec
Ensure common memory reporters get registered in GPU process. r=ahale

Comment 21

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/5c62ffef25ec

Comment 22

[Lee Salzman [:lsalzman]]

Attachment: Bug 1945997 - Avoid duplicate memory reports in DrawTargetWebgl. r?aosmond

ResetPathVertexBuffer could accidentally report memory more than once.

Comment 23

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

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e41f961e9710
Avoid duplicate memory reports in DrawTargetWebgl. r=aosmond

Comment 25

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/e41f961e9710