rect_union_add takes a pixman_box32_t by value, and passes it along by
value to internal helpers. render_pass_mark_box_updated which is the
only caller receives the pixman_box32_t by reference, so just plumb it
through that way.
Results in a 13% improvement in CPU time when using the Vulkan renderer
on the stacked/clip200/1024 benchmarks on my machine.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Similar to what we have already done for gles2. To simplify things we
use the staging ring buffer for the vertex buffers by extending the
usage bits, rather than introducing a separate pool.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
We are spending quite significant CPU time walking through the clip
rects, taking a pixman box, converting it to a wlr box, intersecting it
and ultimately converting it back to a pixman box before adding it to
the rect union.
Just intersect the clip region once ahead of time, and use pixman boxes
the entire way. This also makes it easy to bail early if nothing
intersects.
Gives a small 97.95% reduction in CPU time for the Vulkan renderer in
the grid/clip200/1024 benchmark.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Implement a ring-buffer that uses timeline points to track and release
allocated spans. We add larger ring-buffers when it fills, and remove
them when they have been unused for many collection cycles.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Uses the EXT version of VK_PIPELINE_COMPILE_REQUIRED in `vulkan_strerror` func since it requires
Vulkan 1.3, switch to VK_EXT_global_priority instead of VK_KHR_global_priority which is only
promoted to core in Vulkan 1.3 as well.
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.
When we're reading from a DMA-BUF texture using implicit sync, we
need to (1) wait for any writer to be done and (2) prevent any
writers from mutating the texture while we're still reading. We
were doing (1) but not (2).
Fix this by calling dmabuf_import_sync_file() with DMA_BUF_SYNC_READ
for all DMA-BUF textures we've used in the render pass.
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.
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")
