User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

Under normal use, GPU memory usage increases over time. This behaviour existed at the beginning, but then it was gone and is now back again.

See screenshots of the usage of the GPU memory of the task manager
The GPU memory is release when the window is closed that was opened at startup:

1. opening a new window
2. close the window that was opened at startup

Actual results:

The GPU memory usage increases over time and never goes back.

Expected results:

GPU memory usage should not increase over time until the maximum is reached.

Here is the screenshot of the Taskmanager after closing the window that was opened at startup.

With Build ID 20200212093201 it is better, but the memory usage remains high - normal between 0.4-0.5 GB.

I've been testing this today on a Win10 + nVidia GTX 1050, with current m-c build on a 4k screen (3840 x 2160) on a few pages, and found some interesting results!

I tested three configurations, rapidly scrolling up and down on each page. In each case, the WR usage seemed stable per-page, which probably means we're not leaking video memory. The baseline usage without Fx open is 0.4-0.5 GB.

(1) WR + DirectComposition (default if WR is running on Win10 now).
(2) WR without DC (disable gfx.webrender.compositor and restart).
(2) Gecko with WR disabled (enable gfx.webrender.force-disabled and restart).

https://en.wikipedia.org
(0) 0.5 GB
(1) 0.5 GB
(2) 0.7 GB

https://reddit.com
(0) 0.8 GB
(1) 0.7 GB
(2) 1.8 GB (seems to grow quickly during scrolling, until it reaches a steady state of 1.8 / 2.0 GB, maybe lots of FLB layers?)

So, it seems that on some pages we might be using a bit more video memory in DC mode than default WR mode, which we should investigate, but it doesn't seem like a huge problem. It also seems like, at least in this small sample, we're using significantly less memory with WR+DC than with normal Gecko running with D2D + FLB.

If the findings above are correct (that we're generally better on memory than without WR), this is probably something we should look into, but not a super high priority.

Geisler, are you able to test on your machine the configurations above and see what kind of numbers you're seeing for each of those configurations? It's also likely that it depends quite a lot on page content what those usage values will be (also possible that we do have a GPU memory leak and only some pages / configurations expose it).

Setting 1
gfx.webrender.compositor=true
available by user: Enabled

Setting 2
gfx.webrender.compositor=false
disabled by user: disabled via gfx.webrender.compositor

Setting 2
gfx.webrender.force-disabled=true
unavailable by runtime: No DirectComposition usage

With settings 2 and 3 the behaviour is similar. Setting 2 was also the solution at the time when the phenomenon occurred the first time.

I was trying to find the trigger. The phenomenon occurs increasingly on sites like reddit, Twitter, Facebook, etc. where videos are loaded and displayed. On the https://www.anisearch.com site, the memory is also used more and is no longer fully released.

I was trying to find the trigger. The phenomenon occurs increasingly on sites like reddit, Twitter, Facebook, etc. where videos are loaded and displayed. On https://www.anisearch.com the memory is also used more and is no longer fully released.

As written above, the phenomenon has occurred before, was gone until shortly after the release of 75.0a1 and is now occurring again.

There was a bug that was a blocker for the default activation of Webrender on Windows. The fix of this bug must have indirectly fixed the reason, because then the memory usage was normal. But I can't remember the number.

I have tried to reproduce the high memory usage with the page https://www.anisearch.com. The most effect has the change of the main menu items.

With setting 1 the memory usage increases over the time and will never be complet released - even when closing the tab.

With setting 2 the memory usage increases over the time too, but it will be released - not immediately, it takes time.

I spent some more time trying to reproduce this today using the sites mentioned above, without any lucky so far.

I added some logging to the DCLayerTree code and it seemed that surfaces and tiles were correctly being destroyed when no longer needed, I couldn't identify any leak there.

I wonder if there might be a leak in the video surface code in Gecko, that is triggered by compositor mode being enabled? Sotaro, would you be able to take a look at this and see if you can reproduce?

I tried to reproduce the memory leak, but I failed to reproduce it until now. There might be a hidden tip to reproduce it. About video surface handling, there is no difference between enabling compositor and disabling compositor in gecko.

Geisler, can you upload about:support to this bug? Thanks.

I see Error: WMF VPX video decoding is disabled due to a previous crash. in the config log above. Could that cause higher memory usage and/or leaks in a code path that we weren't expecting to see?

Jeff, any ideas on this - perhaps we could get a couple other people in the office to see if they're able to repro?

I enabled the feature in the release version. Here the behavior and use of the GPU memory is fine - I couldn't reproduce them in a quick test.

Decision Log
WEBRENDER: opt-in by default: WebRender is an opt-in feature
available by user: Qualified in release

WEBRENDER_COMPOSITOR: disabled by default: Disabled by default
available by user: Enabled

WEBGPU: disabled by default: Disabled by default

(In reply to Glenn Watson [:gw] from comment #11)

I see Error: WMF VPX video decoding is disabled due to a previous crash. in the config log above. [...]

It's bug #1570046.

Rares, are you able to reproduce this problem anywhere?

I wasn't able to reproduce anything leak like on a R7 200 Series with the same driver.

Geisler, I was wondering if it would be possible for you to get a gpuview trace of the leak happening. You can get gpuview by downloading the https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/ and installing the Windows Performance Toolkit.

Once you have it. Please open an Administrator command prompt and run log_mem in the C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\gpuview directory to start the trace. After you've noticed the leak you can run log_mem again to stop the trace. This should create a Merged.etl which we'd like to see.

Hi Jeff, we started testing this issue on different machines with different settings and here are the results, the only thing is that the more we stayed on reddit.com scrolling, waiting for the page to load scrolled again, the more GB would be used:

Dell Laptop with 2 GPU's (intel active) WebRender on - 1.2 GB out of 7.9GB
WR on but gfx.webrender.compositor = false - 1.5 GB out of 7.9GB.
gfx.webrender.force-disabled = true - 3GB out of 7.9GB

Desktop with Nvidia GeForce GT 730 GPU WebRender on - 2.2 GB out of 10GB
WR on but gfx.webrender.compositor = false - 1.5 GB out of 10GB.
gfx.webrender.force-disabled = true - 2.4GB out of 10GB

Desktop with AMD Radeon RX550/550 Series WebRender on - 0.9 GB out of 10GB
WR on but gfx.webrender.compositor = false - 0.9 GB out of 10GB.
gfx.webrender.force-disabled = true - 1.9GB out of 10GB

Desktop with Intel HD Graphics 630 WebRender on - 2.5 GB out of 7.9GB
WR on but gfx.webrender.compositor = false - 1.7 GB out of 7.9GB.
gfx.webrender.force-disabled = true - 2.7GB out of 7.9GB

And Yes , I was able to reproduce the issue mentioned in Comment 14 but only after I've allowed Autoplay - Audio and Video from about:preferences#privacy.

(#0) Error WMF VPX decoder just crashed; hardware video will be disabled.
(#1) CP+[GFX1-]: WMF VPX video decoding is disabled due to a previous crash.

Un-assigning for now, as I haven't been able to repro this locally, and other tests from the comments above suggest that the reported memory usage is still lower than with WR disabled.

Doesn't seem to be anything actionable here, reopen if that's not the case.