On Wayland, if the wl_drm interface is not available, for example if the
compositor is using the proprietary NVIDIA driver along with their egl-wayland
library, the device_select layer will fail to initialize. However, the failure
path will unconditionally call wl_drm_destroy even though info.wl_drm would be
NULL in that case. This can cause a segfault in libwayland-client.so.
To fix this, check if info.wl_drm is NULL before calling wl_drm_destroy. This
way, initialization will fail gracefully even if that interface is not present.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10598>
Currently, a resized window results in an VK_ERROR_OUT_OF_DATE_KHR. But,
this seems to go against the spec, which suggests returning
VK_SUBOPTIMAL_KHR if the surface extent no longer matches the window
extent. (It does not *require* the WSI actually scale the contents, only
encourages doing so "if possible")
More to the point, VK_SUBOPTIMAL_KHR is the correct status to return if
the client *can* continue presenting to this swapchain, even if the
result will look wrong / "suboptimal". It's the client's decision on
when exactly to recreate the swapchain in this case, and the client may
very well end up wanting to continue presenting for a frame or two, to
prevent flooding the driver with swapchain recreations (which can result
in the window appearing visually "frozen" while resizing).
This change makes live resizing *significantly* smoother in e.g. mpv.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3196>
If the swapchain already does not match the current geometry at the time
of creation, set the initial status to VK_SUBOPTIMAL_KHR as a way to
inform clients to please resize the swapchain.
This solves a race condition where users have no way of knowing if the
surface extent changed in between the user querying the current extent
and creating the swapchain, and might end up missing a resize event
because of it, since XCB_PRESENT_CONFIGURE_NOTIFY is not yet being
handled.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3196>
Until now, the WSI code would rely on VK_EXT_pci_bus_info to check if the
WSI device matched the DRM device used for display. If they matched, then
it would allow direct presentation of the swapchain images, otherwise
it would fallback to a blit path through a linear buffer.
Unfortunately, this only works for PCI devices, so embedded GPUs would
always fail the test and fallback to the prime blit path, incurring in a
performance penalty due to the extra blit.
With this change driver backends have the possibility to attach a
callback to the WSI device to take control over that decision and have
freedom to make that choice according to their own platform particularities.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5917>
Present operations do not necessarily complete after the requested
time; if the CRTC has been blanked, they will complete
immediately. This means we cannot use the MSC value to tell when a
present has finished.
Instead of using MSC, track whether each present is complete by serial
number, which is the low 32-bits of the SBC value. This value is
provided in the present_pixmap request and returned in the present
complete notify event.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
With the new Vulkan Video extensions a bunch of enum values have been
added. The problem is that those are behind #ifdef so our generated
code complains that we using enum values not defined.
Since we're not using enum names but integer values, we can silence
all those by casting the enum type to int64_t.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10304>
The meson.build was unaware of transitive dependencies introduced by
Python imports.
Android still needs fixing. But I did not update the Android files lest
I break the build.
Ideally, we would fix this by using a Python runner that generates
a depfile, similar to how meson creates depfiles for C files by passing
flags -MD -MQ -MF to gcc. But this patch gets the job done, without
stalling on the ideal general solution, by manually tracking the Python
imports in new 'foo_depend_files' variables.
CC: mesa-stable@lists.freedesktop.org
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1466>
The commit below was already meant to do this, but accidentally missed
this part.
Fixes stutter when the frame-rate drops below the refresh rate.
Fixes: e8f50bd600 "wsi/x11: Treat IMMEDIATE present mode the same as
MAILBOX for Xwayland"
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10026>
Similar to 641320ce02 and 68bb26af63 to avoid Android build errors
Fixes the following building error:
In file included from external/mesa/src/vulkan/util/vk_util.c:28:
external/mesa/src/vulkan/util/vk_util.h:248:30: error: implicit declaration of function 'ffs' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
return (gl_shader_stage) (ffs((uint32_t) vk_stage) - 1);
^
1 error generated.
Fixes: 06ebbde630 ("vulkan: Deduplicate mesa stage conversion")
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10023>
If a VkRenderPassInputAttachmentAspectCreateInfo is provided, we use the
aspects specified there. Otherwise, we default to every aspect in the
format. For attachments which are not input attachments, aspectMask is
left zero.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8857>
