Closed Bug 1711477 Opened 6 months ago Closed 1 month ago

Texture cache compaction

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
95 Branch
Tracking Status
firefox95 --- fixed

People

(Reporter: nical, Assigned: nical)

References

(Blocks 1 open bug)

Details

Attachments

(7 files, 1 obsolete file)

The majority of pages fit in a single cache texture for images and a single one for glyphs. However some push us over the limit and trigger an the allocation of a new large 2k by 2k texture. So far so good, however what tends to happen is that after a while both textures are mostly empty but there is a handful of items in each textures keeping them allocated forever and we never get to reclaim that memory even though we don't need it.

It would be useful to copy items from a texture to another when the source textures has less than 20% of its space allocated and the destination is less than half full or some other simple heuristic.

We could decide to only trigger this on "cheap" frames (less than N picture tiles invalidated), and on memory pressure events.

The newer version contains a few new APIs that will be needed for texture cache compaction:

  • An iterator of allocated items.
  • A way to associate AllocIds with a stable index.

This will be used in a followup patch to defragment the texture cache.

Depends on D128251

The initial implementation uses the composite shader just like the upload code, but it's a bit messy. I'll add a simpler more specialized shader for that in a followup.

Depends on D128252

Depends on D128253

The previous heuristics would set a threshold in number of allocated bytes per texture type, continuously evict a fixed number of items above the threshold and stop evicting below the threshold.

The new logic lowers the amount of allocated bytes below which we stop evicting, and make eviction above the threshold more progressive, only evicting very cold items if the the cache pressure is low and ramping up how aggressively items a are evicted along with the cache pressure.
In addition, we maintain a minimum of cache pressure until there is a only a single texture atlas allocated for a given shared texture type.

The above combined with the texture cache compaction code ensures that even after a difficult workload, the texture cache eventually settles back to a single texture atlas per type with reasonable fragmentation.

Depends on D128254

Using the composite shader for that was very clunky. It might even be faster thanks to how much simpler the shader is and it's use of texel fetch instead of linear sampling.

Depends on D128255

Attachment #9244545 - Attachment is obsolete: true
Pushed by nsilva@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a7a4ab2e72a9
Update etagere to 0.2.6. r=gfx-reviewers,jrmuizel
https://hg.mozilla.org/integration/autoland/rev/8d9c84a52b94
Add a way to get from atlas alloc ID to texture cache handle. r=gfx-reviewers,gw
https://hg.mozilla.org/integration/autoland/rev/f99634c97a75
Add support for copying from a cache texture to another. r=gfx-reviewers,kvark
https://hg.mozilla.org/integration/autoland/rev/1abf5dd04917
Texture cache compaction r=gfx-reviewers,kvark
https://hg.mozilla.org/integration/autoland/rev/13af5105d7f6
Improve the texture cache eviction heuristics. r=gfx-reviewers,kvark.
https://hg.mozilla.org/integration/autoland/rev/e2d91fc7ef84
Use a dedicated shader for copying from a texture to another. r=gfx-reviewers,kvark
You need to log in before you can comment on or make changes to this bug.