Closed Bug 1654929 Opened 1 year ago Closed 1 year ago

DCLayerTree::mFrameBuffers grows without bound

Categories

(Core :: Graphics: WebRender, defect)

defect

Tracking

()

RESOLVED FIXED
mozilla80
Tracking Status
firefox-esr78 --- disabled
firefox78 --- wontfix
firefox79 --- wontfix
firefox80 --- fixed

People

(Reporter: jrmuizel, Assigned: jrmuizel)

References

Details

Attachments

(1 file)

We need to clean it up

Blocks: 1654013

This should help keep things from growing out of control.

Assignee: nobody → jmuizelaar
Status: NEW → ASSIGNED

I tested this locally with tab cycling and seemed to make a pretty big difference. It looks like there might still be some other leaks but this was a big one.

Pushed by jmuizelaar@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/110c1bd73240
Drop old FBOs that we haven't used in a while. r=gw

Comment on attachment 9165788 [details]
Bug 1654929. Drop old FBOs that we haven't used in a while.

Beta/Release Uplift Approval Request

  • User impact if declined: Memory usage (Both CPU and GPU) can grow without bound in the GPU process when WebRender is enabled. It's not known how big a problem this is in the wild but it's pretty easy to reproduce the problem and grow the GPU process arbitrarily large by aggressively tab cycling for a couple of minutes (See bug 1654013).

This code dates back to when DirectComposition was enabled for WebRender (around the beginning of the year) so we've already shipped it and it obviously isn't catastrophic. On the other hand, a lot of active reporters test on Nightly and so a slower leak like this might not be as obvious. It may also impact people with less memory more severely which is something to take into consideration as 79 rolls out WebRender to a set of users with lower end/older hardware.

  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce: https://bugzilla.mozilla.org/show_bug.cgi?id=1654013#c5
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): The patch is pretty easy to understand and takes a pretty conservative approach to freeing memory so it should not have a big impact on performance. I tested it locally and it does prevent the leak.

The patch touches code that runs on every paint so it should be reasonably well tested even with a simple smoke test.

  • String changes made/needed:
Attachment #9165788 - Flags: approval-mozilla-release?
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80

There's no driver for an RC2 and since we already shipped several releases with this bug it doesn't seem to be one. Let's have it bake in 80 beta and consider it as a ridealong for a potential 79.0.1 dot release.

80 ships next week, there are no plans for a 79 dot release.

Attachment #9165788 - Flags: approval-mozilla-release? → approval-mozilla-release-
You need to log in before you can comment on or make changes to this bug.