Introduce properties for the main renderer and allocator the compositor
wants wlroots to use when it needs to blit to a staging buffer during
multigpu. We need to perform an additional blit if the modifier is not
compatible with the target GPU.
We need this really slow path if the user is using GPUs that don't have
common compatible modifiers. One example of a vendor that doesn't support
rendering to a LINEAR modifier (which otherwise should always exist)
is NVIDIA.
We also need to introduce allocator variants to wlr_raster_upload_texture
and wlr_raster_attach so that the given allocator can be used to
allocate a stanging buffer to aid in blitting
If the compositor is running without a renderer, that means that
the compositor must be driven by something external that may or may not
be there. So we have two scenarios:
1. This compositor is currently being watched and driven by some
external source that is consuming buffers. This is okay, because
during the commit handler `surface->current.buffer` and
`surface->buffer_damage` will be usable and things will be handled
like normal.
2. Things break however if the compositor is not currently driven. This
however is commonly temporary. Something may not be interested right now,
but later it can be. In this case we have to accumulate state until
this external consumer is ready. Here, we have to accumulate the
`buffer_damage` and keep the buffer locked until the consumer is ready.
`wlr_surface_consume` needs to be called when the state of this surface
was consumed so that it is safe to release these resources.
wlr_compositor will now wait for the current buffer to be released before
clearing relevant state. For now, this will always happen at the end of
the commit so there should be no functional change here.
Since wlr_raster supports wlr_compositor usage with and without a renderer,
use it for wlr_curosr so cursors support running on a surface without
a renderer.
The prerelease signal lets users do things things at the last moment
that would be inappropriate to do on the release signal. Inside the
prerelease signal, it is allowed to lock the buffer and also
upload/import the contents of the buffer to a texture.
After a connector scan, new connectors might have appeared and old ones
gone away. At this point, old CRTC allocations are already gone, while
new allocations are not yet needed. Skip the call.
If a surface with an existing buffer has a syncobj surface state created
without committing a new buffer with associated timelines, callers will
see the surface as having a syncobj state and may try to use it, but
calling the signal_release_with_buffer helper at this time will assert
on the lacking release timeline.
As this is a valid situation, remove the assert and replace it with an
early return so that callers do not need to explicitly check for the
presence of valid timelines.
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3895
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
