Eight million pixels and counting: improving texture atlas allocation in Firefox (2021) | Hacker News Reader

Eight million pixels and counting: improving texture atlas allocation in Firefox (2021)

nical.github.io

56 pointsfanf213 comments

Dumb question: it seems like this assumes that once you have allocated a spot within an atlas, you can't move it. But wouldn't it be a within-GPU transfer to garbage collect a fragmented atlas into a new texture?

If so, then could you do a fast but messy allocation, then clean it up when you run out of space, or are about to? Or you could pull in more traditional GC tricks: have one texture that gradually accumulates long-lived images (the tenured region), and divide up another region into two semispaces that you do fast bump-like allocations into and then compact from one to the other when it fills up. You could even incrementally repack, assume copying within and between atlases works in the first place.

(I'm the author of the blog post) Yes, WebRender could repack it's texture atlases. A lot of stuff of various sizes go in there so I would not want to rely on repacking large amounts of pixels frequently but it could, among other things, help with more quickly converging back to a single texture atlas after an allocation spike. To my knowledge WebRender cannot move data within a texture using the OpenGL version it's restricted to.

Just wanted to let you know that you converged on the same solution (nested 1d allocators) that I came up with for Google Maps back in 2013ish.

We also made heavy use of allocation bitmaps and a few other tricks to ensure that the texture allocator does zero dynamic memory allocation at runtime, as that could cause performance bubbles.

Oh, and we had similar visualizers for atlas usage but they were live views in a popup window rendered via canvas.

Google Maps extends atlases vertically in the rare case that they overflow by creating a new taller texture and blitting the old one into it.

Since it's device local it takes almost no time.

Texture atlases are becoming a relic now that bindless rendering is a thing, but I suppose Firefox still has to be able to run on low spec Android devices with poor Vulkan support, or no Vulkan support at all. Maybe one day they'll finally get to follow game engines in deleting all of their atlas hacks.

And Linux with no Vulkan support in many drivers, and macOS with no Vulkan support at all, and on all the Windows devices without Vulkan support... Vulkan is far from widespread still

D3D12 and Metal can do bindless as well, I mention Vulkan on Android because that's consistently the platform which lags the furthest behind everything else in real-world GPU feature support and driver quality.

I agree, but

> Maybe one day they'll finally get to follow game engines in deleting all of their atlas hacks.

Are there any public game engines using bindless resources? Unreal seems to be the only one, but they pretty much don't care about low-end Android.

Firefox's user base is also full of old Intel integrated GPUs that don't support bindless. The day WebRender can start relying on it cannot come soon enough but it's a long way off.

Texture atlases will still be a thing when you're dealing with thousands or tens of thousands of glyphs in a glyph cache (some languages end up with a combinatorial explosion of glyphs due to accent marks and stuff).

When I needed to create texture atlases I copy-paste from Mikko Mononen.

Here’s a C++ port of his C version: https://github.com/Const-me/nanovg/blob/master/src/FontStash...

(2021)

Reply on news.ycombinator.com