| Age | Commit message (Collapse) | Author |
|---|
|
The spec [1] says that the maximum value for a mediump float
is at least 2¹⁴ in section 4.5.2. However, when using a 4k
resolution texture coordinates will exceed this value. This causes
issues on drivers which implement mediump as a 16-bit [2].
Switch to highp. There's a twist: on GLES2, support for highp is
optional. So we need to guard it with cute GL_FRAGMENT_PRECISION_HIGH
ifdefs.
[1]: https://registry.khronos.org/OpenGL/specs/es/2.0/GLSL_ES_Specification_1.00.pdf
[2]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21082
|
|
Doesn't matter a lot, but let's try to be consistent with the
GL headers.
|
|
Fail with a clearer error when the requested size is too large.
Without this, we allocate a buffer with a size smaller than what
was requested.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3975
|
|
|
|
|
|
|
|
|
|
Some formats like YUV are only supported by Mesa for sampling, not
for rendering. However we always unconditionally added the INVALID
modifier to the list of render formats.
Check whether all modifiers are external-only, in that case, don't
add INVALID to the list of render formats.
|
|
EGL_EXT_image_dma_buf_import_modifiers [1] uses EGLint to carry
formats. We were casting it to int (which may not be the same
width) and uint32_t (which may change the value).
Instead, use EGLint everywhere.
[1]: https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
|
|
|
|
We sometimes used HAS_, sometimes polluted the LIBINPUT_ namespace,
etc.
|
|
Removes a project argument.
|
|
Use early returns to remove the !renderer checks.
|
|
The Vulkan spec doesn't guarantee that the driver will wait for
implicitly synchronized client buffers before texturing from them.
radv happens to perform the wait, but anv doesn't.
Fix this by extracting implicit fences from DMA-BUFs, importing
them into Vulkan as a VkSemaphore objects, and make the render pass
wait on these VkSemaphores.
|
|
|
|
|
|
We always have a stage_cb at this point.
|
|
pre_cb was an alias for stage_cb->vk. Let's just use a single
variable instead.
Additionally, early return when vulkan_record_stage_cb() fails.
We were crashing in vkCmdPipelineBarrier() if that happened.
|
|
Skip clears with an empty scissor.
Fixes the following validation error:
00:00:09.734 [wlr] [render/vulkan/vulkan.c:61] Validation Error: [ VUID-vkCmdClearAttachments-rect-02682 ] Object 0: handle = 0x62600001b100, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0xadbd476f | CmdClearAttachments(): pRects[0].rect.extent.width is zero. The Vulkan spec states: The rect member of each element of pRects must have an extent.width greater than 0 (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdClearAttachments-rect-02682) (VUID-vkCmdClearAttachments-rect-02682)
|
|
|
|
|
|
We were filling VkTimelineSemaphoreSubmitInfoKHR.pSignalSemaphoreValues,
but we were missing VkSubmitInfo.pSignalSemaphores.
This was causing VkTimelineSemaphoreSubmitInfoKHR.pSignalSemaphoreValues
to be ignored. By chance, the render command buffer was using the
next timeline point, so we were waiting for that instead.
|
|
Move it down, right before it's used.
|
|
|
|
struct wlr_vk_format_props contains a mix of properties for shm
and dmabuf, and it's not immediately clear which fields are for
which kind of buffer. Use a nested struct to group the fields.
|
|
|
|
|
|
Use a more appropriate message on
vkGetPhysicalDeviceImageFormatProperties2() error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DRM_FORMAT_INVALID is zero. Let's just omit the fields to make the
table more readable.
|
|
|
|
|
|
"format" is already in the name, no need to repeat ourselves.
`format->vk_format` sounds a bit redundant.
|
|
|
|
To be able to add support for newer versions without breaking
changes.
|
|
Make it clear this is a helper consuming a wlr_renderer. We'll
add a lower-level create() function which doesn't take it in the
next commit.
|
|
Right now the Vulkan renderer blocks until the frame is complete
after rendering. This is necessary because Vulkan doesn't
interoperate well with implicit sync we use everywhere else.
Use the new kernel API to import a sync_file into a DMA-BUF to
avoid blocking.
|
|
References: https://lore.kernel.org/dri-devel/20220506180216.2095060-1-jason@jlekstrand.net/
|
|
We need to wait for the pending command buffer to complete before
re-using stage buffers. Otherwise we'll overwrite the stage buffer
with new contents before the texture is fully uploaded.
|
|
We need to wait for any pending command buffer to complete before
we're able to fully destroy a struct wlr_vk_texture: the Vulkan
spec requires the VkDescriptorSet to be kept alive.
So far we've done this in vulkan_end(), after blocking until the
command buffer completes. We'll soon stop blocking, so move this
logic in get_command_buffer(), where we check which commands buffers
have completed in a non-blocking fashion.
|
|
export_imported is never used, and dmabuf_flags is already checked
in query_modifier_support().
|
|
vkCmdCopyBufferToImage requires that the buffer offset be a multiple
of the texel block size, which for single plane uncompressed formats
is the same as the number of bytes per pixel. This commit adds an
alignment parameter to vulkan_get_stage_span which ensures that the
provided span (and the sequence of image copy operations derived which
use it) have this alignment.
|
|
Since this does not have a matching _SRGB-type vulkan format, add a
new shader variant/pipeline to perform the sRGB->linear texture
conversion.
|
|
Let's just forward-declare struct wlr_backend instead.
We need to fixup the Vulkan renderer: it needs makedev(), which
got included by chance via <wlr/backend.h> → <wlr/backend/session.h>
→ <libudev.h>.
|
|
|
