The previous commit adds a synthetic NV12 render format to the set, but
it is contingent upon the presence of the R8 and GR88 render formats.
Signed-off-by: Andri Yngvason <andri@yngvason.is>
As mentioned in the previous commit message, we can't create an RBO out
of an NV12 buffer in GL ES2.0. Instead, we render in 2 passes to 2
separate RBOs.
This could be made more generic by having a lookup table for the
parameters that need to be set for each plane for any given format, but
as of yet, I see no practical reason for implementing any other kind of
YCbCr target buffer rendering as NV12 seems to be the only format that's
commonly supported by hardware video encoders.
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Rendering to NV12 buffers is not directly supported in GL ES2.0, but can
be implemented by rendering in 2 passes to 2 different EGL images.
This change makes provisions for multiple EGL images inside a
wlr_gles2_buffer and adds a special case for mapping NV12 buffers to
multiple EGL images.
Signed-off-by: Andri Yngvason <andri@yngvason.is>
This allows using the vulkan renderer on platforms that provide all
the necessary Vulkan extensions.
Tested on a Mali G52 platform with Mesa 26.0.0 and 25.3.5, which only
support Vulkan API 1.0.
We'll need to grab textures from there in the next commit.
Also rename it to better reflect what it does: synchronize release
fences after a render pass has been submitted.
Fixes d1c88e9 "render/vulkan: add linear single-subpass"
`find_or_create_render_setup` still assumed a single-buffer setup
always implied use of an srgb format
The important bit here is whether this is using a single or two
sub-passes. The flag isn't used for anything else.
Preparation for an upcoming one-subpass codepath.
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.
