If NULL is returned by vkGetDeviceProcAddr(), either the driver
is buggy, either the wlroots code is buggy. For a valid device and
command name, drivers are not allowed to return NULL per the spec.
This mirrors what the GLES2 renderer does in load_gl_proc().
Added wlr_vk_renderer_get_* functions to allow get the VkInstance,
VkPhysicalDevice, VkDevice, queue family of a wlr_vk_renderer.
Added wlr_vk_renderer_get_current_image_attribs function to allow get
the VkImage of current renderer buffer to use on compositors.
Added wlr_renderer_is_vk function, it's like the wlr_renderer_is_gles2,
returns true if the wlr_renderer is a wlr_vk_renderer.
Added wlr_vk_image_get_attribs function to get a VkImage and it's
extras information (e.g. a VkImageLayout and VkImageFormat of the
VkImage) from a wlr_texture.
Instead of filling the fields one by one, use a struct initializer.
This avoids repeating the name of the variable and is more
consistent with the wlroots code style.
find_extensions() is clunky to use when checking only a single
extension, and it's surprising that it returns NULL on success.
Simplify by replacing it with a check_extension() function which
just checks whether a single extension is in the list.
We were checking whether any of the features was supported. We need
to check if all of them are.
This makes the check consistent with query_modifier_support() above.
From a comment by emersion:
> There is a logic error here: we pass 0xFFFFFFFF to vulkan_find_mem_type, which
> returns an index, and then we logical-and that with mem_reqs.memoryTypeBits.
> Instead we should pass mem_reqs.memoryTypeBits to vulkan_find_mem_type and use
> the result for the memoryTypeIndex field directly. Ideally checking for errors
> (-1 return value) in case no memory type is suitable.
Closes: #3470
This lets the renderer handle the wlr_buffer directly, just like it
does in texture_from_buffer. This also allows the renderer to batch
the rectangle updates, and update more than the damage region if
desirable (e.g. too many rects), so can be more efficient.
Whether a texture is opaque or not doesn't depend on the renderer
at all, it just depends on the source buffer. Instead of forcing
all renderers to implement wlr_texture_impl.is_opaque, let's move
this in common code and use the wlr_buffer format to know whether
a texture will be opaque.
`vulkan_format_props_query` calls `query_modifier_support` which
initializes fields of `props` with allocated memory. this memory is
leaked if `query_modifier_support` does not find a supported format
and shmtex is not supported, as in this case `add_fmt_props` ends
up being false and the allocated fields of `props` are never freed.
They are never used in practice, which makes all of our flag
handling effectively dead code. Also, APIs such as KMS don't
provide a good way to deal with the flags. Let's just fail the
DMA-BUF import when clients provide flags.
This new renderer is implemented with the existing wlr_renderer API
(which is known to be sub-optimal for some operations). It's not
used by default, but users can opt-in by setting WLR_RENDERER=vulkan.
The renderer depends on VK_EXT_image_drm_format_modifier and
VK_EXT_physical_device_drm.
Co-authored-by: Simon Ser <contact@emersion.fr>
Co-authored-by: Jan Beich <jbeich@FreeBSD.org>