Webrender per-window memory overhead is high
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: mesvam, Unassigned)
References
(Blocks 1 open bug)
Details
After updating to v87, I noticed significantly higher memory usage at startup, with the main culprit being the GPU content process. On one profile, it was consuming 4G RAM, with about:memory indicating almost all of it used for webrender textures, with 2.5G reserved for texture cache.
3,832.06 MB (100.0%) -- gfx
└──3,832.06 MB (100.0%) -- webrender
├──3,730.29 MB (97.34%) -- textures
│ ├──2,548.66 MB (66.51%) ── texture-cache
│ ├────406.38 MB (10.60%) ── swap-chains
│ ├────398.91 MB (10.41%) ── render-texture-hosts
│ ├────296.00 MB (07.72%) ── depth-targets
│ ├─────67.50 MB (01.76%) ── upload-staging-textures
│ └─────12.84 MB (00.34%) ++ (4 tiny)
└────101.78 MB (02.66%) ++ images/mapped_from_owner
I do have a lot of tabs open, but they're all lazy loaded, so I can't make sense of why it would use so much memory right at startup. I also seem to be encountering more rendering artifacts, pointing towards some changes in webrender.
Not entirely sure this is a bug, but if it's correct behavior, it'd be nice to know. 4G on startup is suspiciously high and I didn't see any webrender changes in the changelog.
mozregression suggests this may go back as far as 2020-06-06, though the numbers are slightly different. I'll see if I can narrow it down a bit
mozregression found this https://hg.mozilla.org/integration/autoland/rev/e9507c0042be96c52728621968e255d1114e593e to be the one that caused largest change in RAM usage. I guess I just didn't notice it earlier
Ok, my mistake. I think I realize what's going on, and it doesn't seem to have anything to do with v87 or any single change. Forget v87 and the mozregression. I realized it had nothing to do with number of tabs, only number of windows and the resolution of the windows. Memory was high since I had a bunch of windows maximized at 2560x1440
But there were two exacerbating factors that pushed it over the edge
- Memory usage of the GPU process has gone up ~30-40% per window since webrender was rolled out around May 2020. It doesn't seem to be a single change, but series of gradual increases. Heavier pages seem to be more affected. At the extreme end, maps.google.com memory usage is almost doubled since May 2020. Lighter pages like Wikipedia and Google search are closer to 30%.
- I had the sidebar open from the Tree Style Tab add-on. Opening the sidebar seems to have a similar effect as opening another window, effectively doubling the number of open windows and thus the per-window memory overhead
|
||
Comment 5•3 years ago
•
|
||
Indeed, I would expect texture memory to climb linearly with the number of windows and almost linearly with the resolution.
The texture cache itself has a per-window up-front cost that is amortized as you browse around, the side panels tend to add some picture cache tiles which are 1024x512 pixels (times the number of tiles you need for the height of the window so 3 tiles in your case). which also adds up since its per window.
I'm curious about what's up with google maps, but in general what's hurting you most is the per-window memory cost.
We have room for improvement in the texture cache eviction logic, and probably in how we manage picture cache tiles. We should probably aggressively evict caches for unfocused windows that haven't been interacted with for some amout of time. On some platforms we use a single GL context so it would be great if we could share the pool of unused picture cache tiles for all windows on the renderer side, but these platforms might be the ones where we use OS composition and I don't know if we can share OS composition surfaces associated to different windows.
|
||
Updated•3 years ago
|
Memory was high since I had a bunch of windows maximized at 2560x1440
That's also the case for me here: https://bugzilla.mozilla.org/show_bug.cgi?id=1715957
I'm pretty sure this is the same issue.
Note : in my case, most windows are maximized, but about 1∕3 are using only half that definition (that are tiled in a kind of split view, with 2 windows sharing the same screen).
We should probably aggressively evict caches for unfocused windows that haven't been interacted with for some amout of time.
I don't know if it's the way to go on the technical side (you know it better than me), but as an user it would really well fit my workflow, and the extra second (?) and CPU load to render again a window that was not used recently is really worth it.
(In reply to lapineige from comment #6)
That's also the case for me here: https://bugzilla.mozilla.org/show_bug.cgi?id=1715957
I looked at your report and I agree, it seems very similar to my situation. My observation is that the memory usage has slowly increased in Webrender over last year, and those effects are exaggerated on our more pathological use cases.
Evicting unfocused windows would help, but I'm also curious about what made memory usage go up in Webrender over the past year, and if any of those changes could be optimized.
https://bugzilla.mozilla.org/show_bug.cgi?id=1715957#c0
Doing a Minimize Memory Usage instantly reduces memory usage back to normal. In few seconds after that, memory usage starts to increase regularly again, up to the previous extra +6GB in less than 30s.
I also tried your trick of "Minimize memory usage" in about:memory, and I went from 4.3G to 3.6G, releasing ~0.7GB in the GPU process. This is even after waiting for it to go up again, and then refocusing all the windows. If that memory was really unneeded, then it suggests there could be plenty room for optimization.
My observation is that the memory usage has slowly increased in Webrender over last year, and those effects are exaggerated on our more pathological use cases.
In my case that's different: I don't know if it evolved in the past months, but there where a huge memory increase after Firefox 89 upgrade. Like +3~6GB in one blow.
I also tried your trick of "Minimize memory usage" in about:memory, and I went from 4.3G to 3.6G, releasing ~0.7GB in the GPU process.
That's was the normal behavior for me before v89. Flushing memory would reduce memory usage by something like 1GB, sometimes a bit more. Then it would grows again during a long while.
Now it's like ≥4GB every time, and it goes up to the previous value (or similar) in <1min.
I just went from 11.5GB to 7.5GB in a second, 5 seconds later it's 8.4GB, and right now I see the number growing very slowly. Now (1min later) it's 11GB again. Note: I did open a new windows in the mid-time… wait….
I think I found something.
If I Minimize memory usage, it goes back to normal. Then goes higher a bit (like + ≤1GB), just like it did before Firefox 89 (and that was a "normal" behavior). But if I open a new window… here we go, +4GB in less than 5s.
If I do it another time, no real change, more memory but something like +100MB.
And this doesn't happen if I open an empty window. Even 10. But if I open a link in a new window, it happens. If I open an empty new window, then load a link, it happens, but at a slower pace.
|
||
Comment 10•3 years ago
|
||
A couple new findings:
- I don't know if it's related, but when I download something, firefox freezes for a few seconds, and I can interact with it, but it is not displayed until that (display) freeze is over.
- some (all ?) extension pop-up/overlay cause the same kind of freeze. For instance, if you add an article thought Wallabagger, it freezes until the pop-up is gone
- I noticed my system FPS is quite low in most situations if Firefox is open. It's around 30-35 FPS. If I freeze Firefox process, it goes back to normal smooth 60 FPS.
In particular, displaying a video (especially using Firefox, but not only) is very difficult, with very few FPS and a lot of shutters.
I suppose it's because of the VRAM being (almost) totally filled. I don't think I had this issue in the past, but I didn't check. Still I was able to play a heavy game or video without any issue.
|
|
||
Comment 11•2 years ago
|
||
2 more findings :
But if I open a new window… here we go, +4GB in less than 5s.
It is different in fact.
It happens also if I Alt-Tab between 2 Firefox windows. And when a pop-up is displayed (note: most add-ons pop-ups are (almost) freezing the display, just like this bug https://bugs.kde.org/show_bug.cgi?id=414785).
In fact simple alt-tab to any window (non-firefox ones too), or a long press of alt-tab, triggers that VRAM memory issue.
edit: after more testing, I believe I was wrong : even if I do "Minimize memory usage" and touch nothing, after around 3-4 Firefox VRAM consumption goes up again.
To document it, if I do a "Minimize memory usage" right now and monitor VRAM usage using nvidia-smi:
- before : 5863MiB / 5943MiB
- "Minimize memory usage" : VRAM usage goes back to 2.5GB, 2 Firefox process using 300~500MB of VRAM
- stabilising for 2-3s around 700MB
- 1s later : 1300MB
- 1s later : 3995MB (5915MiB / 5943MiB VRAM used), stable then.
If I freeze Firefox process during that first 2 steps (VRAM usage <1GB) I can watch a video without any shutter, or play a video game that does not required more than 3GB of VRAM (~2.5GB of VRAM being used).
So that's definitely a VRAM issue that prevent other programs from displaying their content smoothly.
- Now I also have some weird display glitches (using KDE and Kwin) when resuming from suspend, with some flickering (the screen is really quickly shown upside-down then back to normal, sometimes several times) when display is refreshed (to be precise: when I move the mouse, if if animations are shown). I first believed it was a nvidia (proprietary) driver issue, but in fact it only happens if Firefox process is running (freezing it remove the issue as long as it is frozen, Minimize memory usage does the same for 1~2s).
It goes away after a few seconds, up to 1 min.
Description
•