BT.1886 is different from other EOTFs in that the spec says that offset
b must be in electrical domain, so use the assumed display environment
from the specification as Lmin and Lmax then normalize bt.1886 to
produce optical luminance L in [0, 1]. See discussion at
https://gitlab.freedesktop.org/pq/color-and-hdr/-/merge_requests/63#note_3090016
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
Not all eotf or eotf inverse are well defined for values outside the
intended domain, so just ignore it and clamp it away.
An alternative solution would be to use sign preserving pow here (i.e.
sign(x) * pow(abs(x), p)), however I'm not sure that makes sense or is
defined anywhere. Negative values here are likely a result of colors
being outside the gamut range, so clipping them to 0 is more correct
than mirroring from 0.
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.
A combined image sampler may need several descriptors in a descriptor
set. We are not currently checking how many descriptors are required,
nor is it presumably guaranteed that such multi-descriptor allocation
will not fail due to fragmentation.
If the pool free counter is not zero, try to allocate but continue with
the next pool and fall back to creating a new pool if the allocation
failed.
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/4010
We pass an alpha multiplier plus a luminance multiplier now.
Fixes the following validation layer error:
vkCmdPushConstants(): is called with
stageFlags (VK_SHADER_STAGE_FRAGMENT_BIT), offset (80), size (72)
but the VkPipelineLayout 0x510000000051 doesn't have a VkPushConstantRange with VK_SHADER_STAGE_FRAGMENT_BIT.
The Vulkan spec states: For each byte in the range specified by offset and size and for each shader stage in stageFlags, there must be a push constant range in layout that includes that byte and that stage (https://docs.vulkan.org/spec/latest/chapters/descriptorsets.html#VUID-vkCmdPushConstants-offset-01795) (VUID-vkCmdPushConstants-offset-01795)
Fixes: 56d95c2ecb ("render/vulkan: introduce wlr_vk_frag_texture_pcr_data")
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.
