June 20th, 2024

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

Improving texture atlas allocation in WebRender with the guillotiere crate reduces texture memory usage. The guillotine algorithm was replaced due to fragmentation issues, leading to a more efficient allocator. Visualizing the atlas in SVG aids debugging. Rust's simplicity and Cargo fuzz testing are praised for code development and robustness. Enhancements in draw call batching and texture upload aim to boost performance on low-end Intel GPUs by optimizing texture atlases.

Read original articleLink Icon
Eight million pixels and counting: improving texture atlas allocation in Firefox (2021)

The article discusses the improvement of texture atlas allocation in WebRender, focusing on the development of the guillotiere crate and its impact on texture memory usage in WebRender/Firefox. Texture atlas allocation is crucial for efficiently submitting work to the GPU by grouping drawing primitives into batches. The guillotine algorithm was initially used but was replaced due to fragmentation issues. A new guillotine allocator was developed to address fragmentation efficiently. Visualizing the atlas using SVG format was found to be a powerful tool for debugging and tuning the algorithm. The article also touches on the simplicity and effectiveness of Rust programming language and ecosystem in developing and testing the guillotiere crate. Furthermore, the importance of fuzzing using Cargo fuzz for testing and improving code robustness is highlighted. The article concludes with the exploration of further improvements in draw call batching and texture upload overhead to enhance performance on low-end Intel GPUs. The balancing act between packing more items into fewer textures and cache management is discussed, emphasizing the benefits of better texture atlases in reducing driver overhead and improving performance.

Related

20x Faster Background Removal in the Browser Using ONNX Runtime with WebGPU

20x Faster Background Removal in the Browser Using ONNX Runtime with WebGPU

Using ONNX Runtime with WebGPU and WebAssembly in browsers achieves 20x speedup for background removal, reducing server load, enhancing scalability, and improving data security. ONNX models run efficiently with WebGPU support, offering near real-time performance. Leveraging modern technology, IMG.LY aims to enhance design tools' accessibility and efficiency.

Fixing a memory leak of xmlEntityPtr in librsvg

Fixing a memory leak of xmlEntityPtr in librsvg

Librsvg fixed a memory leak issue caused by mishandling xmlEntityPtr instances in SVG parsing. A wrapper struct with Rust's Drop trait was used for automatic resource deallocation, improving memory management efficiency.

Mip-Splatting: Alias-Free 3D Gaussian Splatting

Mip-Splatting: Alias-Free 3D Gaussian Splatting

The paper introduces Mip-Splatting, enhancing 3D Gaussian Splatting by addressing artifacts with a 3D smoothing filter and a 2D Mip filter, achieving alias-free renderings and improved image fidelity in 3D rendering applications.

Update on GNOME Newton, the Wayland-native accessibility project

Update on GNOME Newton, the Wayland-native accessibility project

The Newton project aims to enhance accessibility on free desktops, focusing on Wayland-protocols, AccessKit, Mutter, Orca, GTK, and libadwaita components. Progress includes running GTK 4 apps in Flatpak sandboxes, with ongoing work to improve Orca functionality on Wayland. Challenges involve optimizing performance and addressing architectural issues for assistive technologies. Future plans may extend support to GNOME Shell UI.

Homegrown Rendering with Rust

Homegrown Rendering with Rust

Embark Studios develops a creative platform for user-generated content, emphasizing gameplay over graphics. They leverage Rust for 3D rendering, introducing the experimental "kajiya" renderer for learning purposes. The team aims to simplify rendering for user-generated content, utilizing Vulkan API and Rust's versatility for GPU programming. They seek to enhance Rust's ecosystem for GPU programming.

Link Icon 5 comments
By @sfink - 4 months
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.

By @jsheard - 4 months
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.
By @Const-me - 4 months
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...

By @gary_0 - 4 months
(2021)