Alyssa Rosenzweig
cd03392c7e
Currently, we always use a hierarchy mask with all levels enabled. While this is efficient for geometry-heavy workloads like 3D games, it is wasteful for 2D applications that draw very few vertices. For drawing just a few textured quads, the overhead of small bin sizes outweighs any performance advantages, so it's a bit slower. More problematically, small bin sizes require tremendous amounts of memory for the polygon lists, leading to significant memory consumption (~10MB) for the polygon list for even the simplest of 2D blits. To reduce our memory footprint, we need to choose our hierarchy masks more carefully. In general, we want to allow small bin sizes for geometry-heavy workloads but not for geometry-light workloads. We estimate vertex count in the driver as a proxy for this, and use a simple heuristic to select a bin size based on the estimated vertex count. None of this is an exact science, and the heuristic could probably be tuned. Nevertheless, the heuristic used (comparing framebuffer size to vertex count) works well in practice, significantly reducing the memory footprint of 2D applications like Firefox without hurting the performance of 3D applications. I originally wrote this patch while diagnosing high memory footprints on my Midgard laptop, which is why only Midgard is in scope here. On Bifrost and Valhall, we have a similar hiearchy mask selection problem. It seems likely that the same heuristic would work there too, but it's a different code path that I have not integrated or tested. I'll leave that for the adventurous reader, to get the memory footprint win there too. (It's also possible the win is smaller on newer Malis than on Midgard, since Arm claims they optimized the tiler data structures on the newer parts. There's probably still some merit to the idea.) On Mali-T860, glmark2 -bdesktop frametime decreased by 1.35% +/- 0.91% at 95% confidence, showing a slight win for 2D workloads No statistically significant difference for glmark2 -bshading:shading=phong, since 3D workloads continue to use the same hierarchy masks. Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19482>
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://mesa3d.org/meson.html>`_): .. code-block:: sh $ mkdir build $ cd build $ meson .. $ sudo ninja install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `OFTC's #dri-devel <irc://irc.oftc.net/dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.