It makes sense to use udmabuf when the backend wants shm, the
renderer wants DMA-BUFs, and we don't have a DRM FD because we're
running with a software renderer (e.g. llvmpipe or lavapipe).
udmabuf can create a DMA-BUF backed by a memfd. This is useful
when running with a software implementation of GL/Vulkan: the memfd
can be passed to the parent compositor via wl_shm and the DMA-BUF
can be imported via the usual APIs into GL/Vulkan.
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.
With this change vulkan renderer can be automatically chosen in two more cases:
GLES2 renderer is disabled at compile time
GLES2 renderer failed to be created
Main purpose of this change is to automatically choose vulkan as renderer when GLES2 renderer is not enabled.
Color transform can have multiple types and these different types
want to store different metadata. We previously stored this metadata
directly on wlr_color_transform even for transforms that don't use it.
Instead, let's take the prior art from wlr_scene where each scene node
is built on a base node. Notice how wlr_color_transform_lut3d now has
a `struct wlr_color_transform base`. This is advantageous in multiple
ways:
1. We don't allocate memory for metadata that will never be used.
2. This is more type safe: Compositors can pass around a
struct wlr_color_transform_lut3d if they know they only want to use a
3d_lut.
3. This is more scalable. As we add more transform types, we don't have
to keep growing a monolithic struct.
The spec for VkMemoryPropertyFlagBits says:
> device coherent accesses may be slower than equivalent accesses
> without device coherence [...] it is generally inadvisable to
> use device coherent or device uncached memory except when really
> needed
We don't really need coherent memory so let's not require it and
invalidate the memory range after mapping instead.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3868
../render/color_lcms2.c: In function ‘wlr_color_transform_init_linear_to_icc’:
../render/color_lcms2.c:26:24: error: incompatible types when returning type ‘_Bool’ but ‘struct wlr_color_transform *’ was expected
26 | return false;
| ^~~~~
The mapping is shared between all users of the stage span, so it should
always map the whole thing and apply the allocation offset to the mapped
pointer.
The use of stage spans for 3dluts was missed when the new cached
mappings were introduced, meaning that it would try to map and unmap
memory that might already have a cached mapping.
Vulkan does not support mapping memory multiple times, so make sure the
3dlut code also uses the cached mapping to avoid segfaults after unmap.
