1624565 - Texture arrays often deallocated and reallocated in the same frame

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Nicolas Silva [:nical]]

I am seeing this happen periodically: in the same frame a 16 layers rgba8 linear texture array from the texture cache is deallocated and one is allocated right away in its place.

Comment 1

[Nicolas Silva [:nical]]

This is happening because we periodically clear the entire cache when calling TextureCache::maybe_reclaim_shared_memory. One way to fix that could be to postpone actually requesting the deallocation to the end of the frame, but I think that the heuristic that decides to clear everything isn't very well suited for how things work now with picture caching and how we allocate texture arrays in large increments.

Comment 2

[Nicolas Silva [:nical]]

Attachment: Bug 1624565 - Eagerly deallocate empty texture arrays in the texture cache. r=gw,jrmuizel

We already have a cooldown from texture cache items being deallocated a certain amount of time and frames after their last use so we can deallocate texture arrays as soon as they are completely empty. We do this at the end of the frame to avoid deallocating and reallocating within the frame. It's better to reclaim texture memory this way than run into maybe_reclaim_shared_memory which will throw away everything and cause new allocations on the next frame.

Comment 3

[Nicolas Silva [:nical]]

Attachment: Bug 1624565 - Avoid clearing the texture cache as often. r=gw,jrmuizel

The current heuristic in TextureCache::maybe_reclaim_shared_memory pretty much clears the cache every 5 seconds. Clearing the cache is prtty drastic though, because it causes us to re-upload data and reallocate several textures on the next frame. We really only want to do it when the savings are big, which happens leff often now that texture array layer count is capped at 16 and that textures are released as soon as they are empty.

This makes us clear the cache less often by augmenting the threshold to 16 megabytes and only considering texture regions that would not be reallocated right away (since we grow some texture arrays more than one region at a time).

Depends on D68050

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cb7a03e73795
Eagerly deallocate empty texture arrays in the texture cache. r=gw
https://hg.mozilla.org/integration/autoland/rev/61582f6d817a
Avoid clearing the texture cache as often. r=gw

Comment 5

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/cb7a03e73795
https://hg.mozilla.org/mozilla-central/rev/61582f6d817a

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Here's a profile of autoland from the evening of the 25th EST https://bit.ly/2UhuAsn
It shows a really bad frame around 4.7s where we do a TextureCacheAlloc and then a TextureCacheFree during the same frame.

Comment 7

[Chris Peterson [:cpeterson]]

Nical, are you expecting your patch's "#n ######## periodic GC" and "#n !! reclaim shared memory" messages to be printed in release builds?

I saw them printed to stdio when running Nightly from the terminal on macOS (because I needed to create a new Firefox profile to test another bug). I don't have exact STR (because I saw the log messages after I quit the browser), but I was watching some YouTube videos in multiple tabs.

#n ######## periodic GC
#n ######## periodic GC
#n ######## periodic GC
#n ######## periodic GC
#n !! reclaim shared memory
#n ######## periodic GC

Comment 8

[Nicolas Silva [:nical]]

Nical, are you expecting your patch's "#n ######## periodic GC" and "#n !! reclaim shared memory" messages to be printed in release builds?

No, these are rebasing accidents. They were removed in https://hg.mozilla.org/integration/autoland/rev/7b36a0458e50