c2b06e1a38
This adds support for sharing the TS buffer, which up until now has been an internal implementation detail, with the outside world. This mainly improves performance with a GPU compositor present, but on i.MX8M also direct to display use-cases benefit. The impact of this change depends on the GPU generation: - old GPUs with a single pipe won't see any difference - GC2000 can skip the TS resolve in the client and will benefit from a more efficient blit into the sampler compatible format when the client buffer contains cleared tiles - GC3000 can directly sample with TS support, so saves both write and read memory bandwidth when the client buffer contains cleared tiles - GC7000 with compression support can keep the client buffer in compressed format, thus saving both read and write bandwidth even for fully filled client buffers - GC7000 coupled to a display unit supporting the compression format (DCSS on i.MX8M) does not even need to uncompress the render buffer for display so will see significant bandwidth saving even when GPU compositing is bypassed There is a slight complication in that the tile clear color isn't part of the TS buffer, but is programmed into state registers in the GPU. To handle this externally shared TS buffers now contain a software metadata area, where the clear color is stored by the driver, so the receiving end of the TS buffer can retrieve the clear color from this area. The compression format is handled in the same way by storing it in the SW meta area. While we can derive the compression format from the color buffer format in most cases, some users, like weston, expect that they can "upgrade" ARGB to XRGB color formats. While this works with plain color formats, as it's just masking a channel, the compression format differs when alpha is in use. Receivers of the TS buffer should thus not try to infer the compression format from the color buffer format, but instead fetch it from the SW meta. The import/export handling of the TS buffer is modelled after the Intel iris driver: we add a separate plane for the TS buffer and fold it into the base resource after the import. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Guido Günther <agx@sigxcpu.org> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
`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.