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>
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>
This needs to be handled specifically for NV12 because GBM does not know
how to allocate NV12 buffers. The approach I've taken is to allocate a
linear R8 buffer for storage and then to import it as NV12 with an
offset for the chroma plane.
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.
I chose to use BT.709 full-range cofficients as that is what is
prescribed by sRGB, annex f.
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 changes 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>
Before this patch the pixman renderer would use "constant padding"
for bilinear scaling which meant that the edges would either be dark
or turn transparent. The effect was most obvious when trying to scale
a single row buffer to a height like 100. The center would have the
desired color but the edges to both sides would fade into transparency.
We now use PIXMAN_REPEAT_PAD which clamps out-of-bound pixels and
seems to match the behavior of the gles2 renderer.
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.
Currently, the glslang check is run every time ninja is invoked,
even with an up-to-date build directory when GLSL shaders haven't
been modified. This is due to glslang not creating any output
file: the _check file never exists so ninja keeps trying to
generate it by running the command.
Unfortunately Meson doesn't support running commands with no
outputs [1]. Create an empty output file to fix this by setting
`capture: true`.
This doesn't work out-of-the-box, because glslang prints messages
to stdout, and provides no way to change this [2]. As a result,
shader errors are not surfaced back to the user - they end up in
the _check file. Workaround this with a thin wrapper which
redirects stdout to stderr when invoking glslang.
[1]: https://github.com/mesonbuild/meson/issues/11506
[2]: https://github.com/KhronosGroup/glslang/pull/4138
Fixes use-after-free on exit of labwc running nested:
==50906== Invalid write of size 8
==50906== at 0x4A85403: wl_list_remove (wayland-util.c:57)
==50906== by 0x40BBAF9: destroy_wl_buffer (output.c:146)
==50906== by 0x40B9B4F: backend_destroy (backend.c:488)
==50906== by 0x409E96F: wlr_backend_destroy (backend.c:68)
==50906== by 0x40B78A6: multi_backend_destroy (backend.c:62)
==50906== by 0x409E96F: wlr_backend_destroy (backend.c:68)
==50906== by 0x4043DA0: server_finish (server.c:788)
==50906== by 0x403AA85: main (main.c:277)
==50906== Address 0xb4435e8 is 40 bytes inside a block of size 136 free'd
==50906== at 0x4A3E8EF: free (vg_replace_malloc.c:989)
==50906== by 0x409C954: buffer_destroy (shm.c:28)
==50906== by 0x40E96F4: buffer_consider_destroy (buffer.c:42)
==50906== by 0x40E9754: wlr_buffer_drop (buffer.c:52)
==50906== by 0x41498DA: slot_reset (swapchain.c:44)
==50906== by 0x4149933: wlr_swapchain_destroy (swapchain.c:53)
==50906== by 0x40CB1FA: wlr_output_finish (output.c:410)
==50906== by 0x40BE00B: output_destroy (output.c:957)
==50906== by 0x40CB2FC: wlr_output_destroy (output.c:436)
==50906== by 0x40B9AFC: backend_destroy (backend.c:481)
==50906== by 0x409E96F: wlr_backend_destroy (backend.c:68)
==50906== by 0x40B78A6: multi_backend_destroy (backend.c:62)
==50906== Block was alloc'd at
==50906== at 0x4A42C13: calloc (vg_replace_malloc.c:1675)
==50906== by 0x409CA84: allocator_create_buffer (shm.c:68)
==50906== by 0x409C7BA: wlr_allocator_create_buffer (allocator.c:186)
==50906== by 0x4149B80: wlr_swapchain_acquire (swapchain.c:102)
==50906== by 0x40C90DA: render_cursor_buffer (cursor.c:246)
==50906== by 0x40C93DC: output_cursor_attempt_hardware (cursor.c:303)
==50906== by 0x40C9A61: output_cursor_set_texture (cursor.c:420)
==50906== by 0x40C9738: wlr_output_cursor_set_buffer (cursor.c:352)
==50906== by 0x40F13A0: output_cursor_set_xcursor_image (wlr_cursor.c:507)
==50906== by 0x40F1B28: cursor_output_cursor_update (wlr_cursor.c:630)
==50906== by 0x40F1C2A: cursor_update_outputs (wlr_cursor.c:657)
==50906== by 0x40F1CF9: wlr_cursor_set_xcursor (wlr_cursor.c:674)
Fixes: 7963ba6a0d
("buffer: introduce wlr_buffer_finish()")
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
