1774099 - High GPU memory usage

Status: UNCONFIRMED

(Core :: Graphics: WebRender, defect)

Description

[Johan Mazel]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

My Firefox version is 91.10.0esr.
I use Debian 11 Bullseye.
My GPU is a GeForce GTX 1060 3GB.
The Nvidia driver version is 460.91.03.

I use nvidia-smi to observe GPU memory usage.
This URL (https://bugzilla.mozilla.org/show_bug.cgi?id=1386177) alone uses 100-140MB of GPU memory. If I open a tab, GPU memory usage does not increase.
Finally, I open a new window.

Actual results:

GPU memory usage increases by 65-70MB.

Expected results:

I would expect that memory usage would be smaller than 60-70MB for each new opened Firefox window.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Lee Salzman [:lsalzman]]

Glenn, does this seem like reasonable memory usage for rendering the example URL in a new tab?

Comment 3

[Glenn Watson [:gw]]

That probably sounds about the expected GPU memory amount per window - to reduce jank from driver allocations, there will be a relatively large pool of texture cache pages and picture cache tiles allocated initially, that we generally don't need to allocate or free from during general browsing.

Comment 4

[Johan Mazel]

I ran some more tests.
A single empty window uses 73MB. If I open this URL, memory usage grows to 103MB.
Two empty windows use 139MB, and three empty windows use 205MB.

It roughly means that if I use 10 windows my memory usage reaches around 700MB and 1.4GB for 20 windows.

Isn't that a bit high?
Couldn't the texture and picture caches be common to all windows?

Comment 5

[Glenn Watson [:gw]]

The texture caches could be shared, yes. However, this is not a trivial change as it means texture uploads from one window now affect the texture cache of all other windows, involving extra synchronization and locking since items may be evicted from the texture cache by one window. It is planned to support this in future, however.

The picture caches can't easily be shared, as there are generally only enough of them around to render the content for the window size (plus a few tiles outside the window so we're not always drawing when scrolling around). With a few scrollable layers typical on each page, it's easy to need 64+ MB just for framebuffer tiles on a high resolution screen to avoid too many driver target allocations during rendering.

What we could do is drop the picture cache tile allocations and reduce the texture cache size for windows that are not currently visible. However, I'm not sure how easy this is to reliably detect on Linux desktop environments.