Re:Eight million pixels and counting: improving texture atla...
by nicalsilva on Saturday June 22, 2024 @03:01PM
(#40761271)
(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.
Re:Eight million pixels and counting: improving texture atla...
by aappleby on Saturday June 22, 2024 @03:25PM
(#40761460)
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.
Re:Eight million pixels and counting: improving texture atla...
by aappleby on Saturday June 22, 2024 @03:26PM
(#40761473)
Oh, and we had similar visualizers for atlas usage but they were live views in a popup window rendered via canvas.
Re:Eight million pixels and counting: improving texture atla...
by aappleby on Saturday June 22, 2024 @03:31PM
(#40761511)
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.
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.