[HN Gopher] Eight million pixels and counting: improving texture...
       ___________________________________________________________________
        
       Eight million pixels and counting: improving texture atlas
       allocation in Firefox (2021)
        
       Author : fanf2
       Score  : 49 points
       Date   : 2024-06-20 17:42 UTC (2 days ago)
        
 (HTM) web link (nical.github.io)
 (TXT) w3m dump (nical.github.io)
        
       | gary_0 wrote:
       | (2021)
        
       | jsheard wrote:
       | 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.
        
         | mort96 wrote:
         | 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
        
           | jsheard wrote:
           | 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.
        
         | FragmentShader wrote:
         | 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.
        
         | nicalsilva wrote:
         | 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.
        
         | aappleby wrote:
         | 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).
        
       | sfink wrote:
       | 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.
        
         | nicalsilva wrote:
         | (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.
        
           | aappleby wrote:
           | 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.
        
           | aappleby wrote:
           | Oh, and we had similar visualizers for atlas usage but they
           | were live views in a popup window rendered via canvas.
        
         | aappleby wrote:
         | 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.
        
       | Const-me wrote:
       | 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...
        
       ___________________________________________________________________
       (page generated 2024-06-22 23:02 UTC)