Converting the LCMS2 transform to a 3D LUT early causes issues:
- It's a lossy process, the consumer will not be able to pick a
3D LUT size on their own.
- It requires unnecessary conversions and allocations: an intermediate
3D LUT is allocated, but the renderer already allocates one.
- It makes it harder to support arbitrary color transforms in the
renderer, because each type needs to be handled differently.
Instead, expose a function to evaluate a color transform, and use
that to build the 3D LUT in the renderer.
Adds linux-dmabuf support to the pixman renderer. The main reason is so
clients can use GPU-accelerated rendering even if the compositor is
using the pixman renderer for whatever reason. This also allows the
pixman renderer to import dmabufs (only RGB/ARGB formats, not YUV for
now).
Since after this change all renderers store a DRM FD, I move the drm_fd
from the individual implementations to the shared wlr_renderer base.
This means that renderer_autocreate() can set pixman's drm_fd for it and
the pixman renderer doesn't have to know about DRM at all.
Originally based on
961edfe44e
Perform a primitive garbage collection of buffers that have not been
used in the past 10 seconds, an arbitrarily selected number.
As garbage collection also makes span buffer allocation happen much more
often, logging on allocation activity leads to a lot of log noise so get
rid of that while at it.
This change makes it possible to support both the direct srgb-format
pipeline and indirect (color-managed, or non-srgb-format) pipeline
for the same render buffer.
Instead of having separate getters for shm formats and DMA-BUF
formats, use the same pattern as wlr_output_impl.get_primary_formats
with a single function which takes buffer caps as input.
This is the last of a set of commits which ensures that both textures
and render buffers can be accessed through _UNORM and _SRGB image
views. While _UNORM image views are not yet used for 8-bpc image
formats, they will be needed in the future to support color transforms
for both textures and render buffers.
This will become necessary when we switch away from scissoring. For the
time being, this cleans things up a bit and allows for a trivial
blending implementation for textures when that comes.
This is implemented by a two-subpass rendering scheme; the first
subpass draws (and blends) onto a linear R16G16B16A16_SFLOAT buffer,
while the second subpass performs linear->srgb conversion, writing
onto the actual output buffer.
