Closed Bug 1678656 Opened 10 months ago Closed 7 months ago

High GPU memory usage on Facebook Win10 (Iris(TM) Graphics 540)

Categories

(Core :: Graphics: WebRender, defect)

Firefox 82
defect

Tracking

()

RESOLVED FIXED
87 Branch
Tracking Status
firefox87 --- fixed

People

(Reporter: jonco, Assigned: mattwoodrow)

References

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

Details

Attachments

(12 files, 4 obsolete files)

42.01 KB, text/plain
Details
107.28 KB, image/png
Details
40.17 KB, text/plain
Details
102.50 KB, application/x-gzip
Details
88.80 KB, image/png
Details
92.21 KB, image/png
Details
95.60 KB, application/x-gzip
Details
97.47 KB, application/x-gzip
Details
95.87 KB, application/x-gzip
Details
65.37 KB, image/png
Details
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

+++ This bug was initially created as a clone of Bug #1674295 +++

I'm cloning bug 1674295 in case there is a graphics issue buried in here too.

Quoting bug 1674295 comment 12:

I can confirm that Facebook is eating up memory on chrome as well (shame on Facebook!) however there are certain differences:
...
As said above the GPU process is eating up the memory on par with Facebook tab. This is happening both on Firefox and on chrome. However in chrome the memory on GPU is immediately released when the Facebook tab become idle (e.g. I don't hit space to load more posts). In Firefox GPU process memory does not decrease.

:jonco, can you attach about:support to this bug?

Flags: needinfo?(jcoppeard)
Attached file about:support for nightly (obsolete) —

Since the initial comment was mine, I assume it is me to provide about:support requested.

Since the original comment was mine, I guess it is me to provide about:support

The issue is similar in Firefox rev 83.
Attached is about:support the the Firefox 83 I'm using at this moment.

From about:support, WebRender was used.

Component: Graphics → Graphics: WebRender
Blocks: wr-memory
Blocks: gfx-triage
Severity: -- → S3
Summary: High GPU memory usage on Facebook → High GPU memory usage on Facebook Win10
Flags: needinfo?(jmuizelaar)

In the memory report from bug 1674295 comment #19 it looks like WebRender is not being used. Tudor, can you attach a new memory report to this bug when you confirmed that about:support has "WebRender" listed as "Compositor"?

Flags: needinfo?(jmuizelaar) → needinfo?(tcflorea)

Jeff, the bug 1674295 comment #19 is not mine.
I will provide a new memory report, about:support and a procexp.exe capture for Nighly restarted with two tabs (Facebook and about:memory) where procexp reports 2G usage for gfxand 1G usage for Facebook tab.
I don't know how to read the about:memory contents but it seems that the firefox memory report and porcexp memory report does not reconcile.

Flags: needinfo?(tcflorea)
Attachment #9189667 - Attachment is obsolete: true
Attached file m201127_2.json.gz

I believe process explorer can report GPU memory usage can you check that as well?

Flags: needinfo?(tcflorea)

The memory usage did not decrease after about one hour.
The system GPU was about 667M and increased to about 800M when I switched to Facebook tab

Flags: needinfo?(tcflorea)

I continued to use Facebook (watch some videos, loaded some more posts) on this Nightly running instance until the memory for GPU porcess was about 4G an for Facebook tab was about 3G. The entire laptop became more and more sluggish/unresponsive so I had to kill the facebook tab's process.
For about two minutes the entire laptop was still unresponsive. During this time the GPU process' memory decreased to something reasonable.
Killing Facebook tab created the following crash report:
https://crash-stats.mozilla.org/report/index/26e0acc4-46a5-45bb-b458-9842c0201127

Can you try setting media.hardware-video-decoding.enabled=false, restarting, and checking if you see similar leaking?

Flags: needinfo?(tcflorea)

I can confirm that setting media.hardware-video-decoding.enabled=false made a big improvement.
The procexp.exe reports GPU process reached at most 350M Private Bytes, 310M System GPU 210M Commited GPU after some browing on Facebook (when the Facebook tab reachd 1.2G usage).
Thank you for this workaround.

Flags: needinfo?(tcflorea)
Depends on: 1679578
Flags: needinfo?(jcoppeard)

Tudor, can you get a new memory report with a Nightly with a build id of 20201215213427 or newer (and media.hardware-video-decoding.enabled set back to true)?

Flags: needinfo?(tcflorea)
Attached file m201216_1.json.gz (obsolete) —

Memory used initially on Facebook page

Flags: needinfo?(tcflorea)
Attached file m201216_2.json.gz (obsolete) —

Memory used after loading a few posts on facebook

Attached file m201216_3.json.gz (obsolete) —

Memory uses after reloading Facebook page

Please note the procexp reports a usage of about 660MB for the GPU process 5084 despite the fact that the the 3rd report appears to suggest some memory release.
Please note that the web process 15776 reports a memory usage of 238.43 MB (60.67%) -- window-objects/top(<anonymized-10737418242>, id=30) for Facebook that does not seem to be released .
The memory is still in use even if I load bing.com on the same tab:
375.03 MB (100.0%) -- explicit
├──226.33 MB (60.35%) -- window-objects/top(https://www.bing.com/?toWww=1&redig=07D8E04E0BD34AE880FDC7837A6933A3, id=30)
│ ├──210.40 MB (56.10%) -- active
│ │ ├──204.31 MB (54.48%) -- window(https://www.facebook.com/REDACTED/)
│ │ │ ├──163.40 MB (43.57%) -- js-realm(https://www.facebook.com/REDACTED/)
│ │ │ │ ├──154.60 MB (41.22%) -- classes
│ │ │ │ │ ├───91.08 MB (24.29%) -- class(Object)/objects
│ │ │ │ │ │ ├──49.32 MB (13.15%) -- malloc-heap
│ │ │ │ │ │ │ ├──44.49 MB (11.86%) ── slots [2]
│ │ │ │ │ │ │ └───4.83 MB (01.29%) ── elements/normal [2]
│ │ │ │ │ │ └──41.76 MB (11.14%) ── gc-heap [2]
│ │ │ │ │ ├───27.08 MB (07.22%) -- class(Function)/objects
│ │ │ │ │ │ ├──23.15 MB (06.17%) ── gc-heap [2]
│ │ │ │ │ │ └───3.93 MB (01.05%) ── malloc-heap/slots [2]
│ │ │ │ │ ├───19.40 MB (05.17%) -- class(Call)/objects
│ │ │ │ │ │ ├──19.36 MB (05.16%) ── gc-heap [2]
│ │ │ │ │ │ └───0.04 MB (00.01%) ── malloc-heap/slots [2]
│ │ │ │ │ ├───13.89 MB (03.70%) -- class(Array)/objects
│ │ │ │ │ │ ├──13.13 MB (03.50%) ── gc-heap [2]
│ │ │ │ │ │ └───0.76 MB (00.20%) ++ malloc-heap
│ │ │ │ │ └────3.15 MB (00.84%) ++ (19 tiny)
│ │ │ │ ├────8.48 MB (02.26%) -- scripts
│ │ │ │ │ ├──5.82 MB (01.55%) ── gc-heap [2]
│ │ │ │ │ └──2.66 MB (00.71%) ── malloc-heap/data [2]
│ │ │ │ └────0.31 MB (00.08%) ++ (3 tiny)
│ │ │ ├───21.16 MB (05.64%) -- dom
│ │ │ │ ├──18.45 MB (04.92%) ── element-nodes [2]
│ │ │ │ └───2.71 MB (00.72%) ++ (5 tiny)
│ │ │ ├───19.69 MB (05.25%) -- layout
│ │ │ │ ├──18.49 MB (04.93%) ── style-sheets [2]
│ │ │ │ └───1.20 MB (00.32%) ++ (2 tiny)
│ │ │ └────0.05 MB (00.01%) ── property-tables [2]
│ │ ├────5.70 MB (01.52%) ++ window(https://www.bing.com/?toWww=1&redig=07D8E04E0BD34AE880FDC7837A6933A3)
│ │ └────0.39 MB (00.10%) ++ (3 tiny)
│ ├───10.79 MB (02.88%) -- js-zone(0x23ffcc9d000)
│ │ ├───5.83 MB (01.55%) ++ (9 tiny)
│ │ └───4.96 MB (01.32%) -- shapes
│ │ ├──4.55 MB (01.21%) ++ gc-heap
│ │ └──0.41 MB (00.11%) ++ malloc-heap
│ ├────3.88 MB (01.04%) ++ js-zone(0x23f8e115000)
│ └────1.26 MB (00.33%) ++ js-zone(0x23f85ed9000)

Flags: needinfo?(jmuizelaar)
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(jmuizelaar)
Depends on: 1686974
Flags: needinfo?(jmuizelaar)

Tudor, we've fixed memory reporting in the GPU process. Is it possible for you to get some a new memory report?

Flags: needinfo?(tcflorea)
Attached file m210124_1.json.gz
Attached file m210124_2.json.gz
Attached file m210124_3.json.gz
Attachment #9193622 - Attachment is obsolete: true
Attachment #9193625 - Attachment is obsolete: true
Attachment #9193627 - Attachment is obsolete: true
Attached image 210124.png

Attached files 9198899: m210124_1.json.gz 9198899: m210124_2.json.gz 9198899: m210124_3.json.gz
contains memory usage after loading a facebook page (1), memory usage after loading multiple posting on the facebook page (2) and memory usage after many minutes of leaving the browser idle when procexp finally reports some memory release.
While this might not be technically a memory leak, the fact that memory is released many minutes makes Firefox and in the end the entire system to become sluggish.

Flags: needinfo?(tcflorea)
Summary: High GPU memory usage on Facebook Win10 → High GPU memory usage on Facebook Win10 (Iris(TM) Graphics 540)

Matt will try to look locally some more.

Flags: needinfo?(matt.woodrow)

It looks like shut down the video decoders for videos that have been paused and scrolled offscreen, but we still frequently retain frames in the video queue (usually 4 from what I see, but seems like it could be up to 10).

If you scroll for a long time, on a feed with a lot of HD videos, then this could accumulate a lot of extra memory usage. We probably want to make sure we drop all but the current frame being displayed (and maybe that too eventually).

I can't reproduce this anywhere near as badly as the reporter, but I do see an accumulation of video frames.

No longer blocks: gfx-triage
Assignee: nobody → matt.woodrow
Status: NEW → ASSIGNED
Pushed by mwoodrow@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/80dd9df92e33
Don't rely on mPlanes to compute RenderTextureHost size, since it's only initialized when used with SWGL. r=jrmuizel
https://hg.mozilla.org/integration/autoland/rev/9bae9681f892
Drain video queue when we put a video into dormant state. r=alwu
Flags: needinfo?(matt.woodrow)
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch
Regressions: 1701120
You need to log in before you can comment on or make changes to this bug.