When dealing with debug logging, it's useful to track when an object's
construction is finished and it's now visible to the client. We can
detect this pretty easily by setting a flag the first time foo_to_handle
is called. As long as drivers only ever call that function at the end
of object construction (they all do to my knowledge), this should be a
reliable mechanism for detecting when a client knows about a handle.
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045>
One of the unfortunate effect of Vulkan starting to use 64bit bitmasks
is that they can no longer be defined using enums because C doesn't
guarantees that enum values will be 64bits.
Vulkan therefore started using those patterns :
static const VkAccessFlags2KHR VK_ACCESS_2_INDIRECT_COMMAND_READ_BIT_KHR = 0x00000001;
This has the effect that we can not longer use those values in
switch/case statements.
This change introduces defines so that we can keep doing this. For now
only VkAccessFlags2KHR/VkPipelineStageFlags2KHR are allowed to be
redefined this way, this list could be changed later (or all bitmask
could be processed this way).
v2: Generate hexadecimal numbers (Jason)
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/9045>
The code here is well-intentioned, but the only way a GetGeometry
request can fail is if you name an invalid drawable. And if we did that,
either our internal state got corrupted, or - more likely - the user
destroyed the window. In either case there's nothing more we can do with
the surface, so report that it's been lost.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13104>
v2: move checks to vk_device_init, ignore struct types from
provisional extensions + lots of cleanups/fixes (Jason Ekstrand)
v3: squash in following patch from Jason:
"vulkan: Restructure vk_physical_device_check_device_features()"
v4 (Jason): Fix a Windows build error
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12867>
==767499== Conditional jump or move depends on uninitialised value(s)
==767499== at 0xEB8E3ED: x11_image_finish (wsi_common_x11.c:1539)
==767499== by 0xEB8E768: x11_swapchain_destroy (wsi_common_x11.c:1640)
==767499== by 0xEB8A8FA: wsi_common_destroy_swapchain (wsi_common.c:505)
==767499== by 0xDE30BA1: anv_DestroySwapchainKHR (anv_wsi.c:242)
==767499== by 0x6817A21: copper_displaytarget_destroy (zink_copper.c:192)
==767499== by 0x6882BE6: zink_destroy_resource_object (zink_resource.c:95)
==767499== by 0x6882447: zink_resource_object_reference (zink_resource.h:198)
==767499== by 0x6882D33: zink_resource_destroy (zink_resource.c:123)
==767499== by 0x688AC97: pipe_resource_destroy (u_inlines.h:145)
==767499== by 0x688AD2E: pipe_resource_reference (u_inlines.h:162)
==767499== by 0x688BE1E: zink_destroy_surface (zink_surface.c:319)
==767499== by 0x688AE0A: zink_surface_reference (zink_surface.h:102)
==767499== by 0x688BE6D: zink_surface_destroy (zink_surface.c:328)
==767499== by 0x67F9CA2: pipe_surface_release (u_inlines.h:134)
==767499== by 0x67FB8AD: zink_context_destroy (zink_context.c:92)
==767499== by 0x5D47B65: st_destroy_context_priv (st_context.c:475)
==767499== by 0x5D49AF2: st_destroy_context (st_context.c:1193)
==767499== by 0x5D5C90F: st_context_destroy (st_manager.c:816)
==767499== by 0x5CC1FC9: dri_destroy_context (dri_context.c:248)
==767499== by 0x658DD63: driDestroyContext (dri_util.c:535)
==767499== by 0x5A30166: drisw_destroy_context (drisw_glx.c:417)
==767499== by 0x5A32484: glXDestroyContext (glxcmds.c:515)
==767499== by 0x5315AEB: glXDestroyContext (libglx.c:332)
==767499== by 0x4AA8E7D: glXDestroyContext (g_libglglxwrapper.c:384)
==767499== by 0x4D5A3F0: ??? (in /usr/lib64/libwaffle-1.so.0.6.1)
==767499== by 0x499DDD5: piglit_wfl_framework_teardown (piglit_wfl_framework.c:638)
==767499== by 0x499E4C5: piglit_winsys_framework_teardown (piglit_winsys_framework.c:238)
==767499== by 0x499F50C: destroy (piglit_x11_framework.c:212)
==767499== by 0x498C535: destroy (piglit-framework-gl.c:210)
==767499== by 0x4F48AF6: __run_exit_handlers (in /usr/lib64/libc-2.33.so)
==767499== by 0x4F48C9F: exit (in /usr/lib64/libc-2.33.so)
==767499== by 0x4AEFD71: piglit_report_result (piglit-util.c:245)
==767499== by 0x499F2CA: process_next_event (piglit_x11_framework.c:139)
==767499== by 0x499F365: enter_event_loop (piglit_x11_framework.c:153)
==767499== by 0x499DF88: run_test (piglit_winsys_framework.c:88)
==767499== by 0x498C5EF: piglit_gl_test_run (piglit-framework-gl.c:229)
==767499== by 0x4022B4: main (primitive-restart.c:45)
==767499== Uninitialised value was created by a heap allocation
==767499== at 0x484086F: malloc (vg_replace_malloc.c:380)
==767499== by 0xE964E85: vk_default_alloc (vk_alloc.c:26)
==767499== by 0xEB8B24B: vk_alloc (vk_alloc.h:43)
==767499== by 0xEB8EAF9: x11_surface_create_swapchain (wsi_common_x11.c:1723)
==767499== by 0xEB8A82A: wsi_common_create_swapchain (wsi_common.c:476)
==767499== by 0xDE30B47: anv_CreateSwapchainKHR (anv_wsi.c:225)
==767499== by 0xE96134F: vk_tramp_CreateSwapchainKHR (vk_dispatch_table.c:6592)
==767499== by 0xD7B88F0: ??? (in /usr/lib64/libvulkan.so.1.2.162)
==767499== by 0x6817796: copper_CreateSwapchain (zink_copper.c:123)
==767499== by 0x6817960: copper_displaytarget_create (zink_copper.c:170)
==767499== by 0x6884C65: resource_create (zink_resource.c:780)
==767499== by 0x6884EC5: zink_resource_create_drawable (zink_resource.c:829)
==767499== by 0x5CC0FE3: copper_allocate_textures (copper.c:199)
==767499== by 0x5CC28C2: dri_st_framebuffer_validate (dri_drawable.c:82)
==767499== by 0x5D5B69A: st_framebuffer_validate (st_manager.c:222)
==767499== by 0x5D5D32D: st_api_make_current (st_manager.c:1102)
==767499== by 0x5CC220B: dri_make_current (dri_context.c:306)
==767499== by 0x658DE23: driBindContext (dri_util.c:588)
==767499== by 0x5A3022A: drisw_bind_context (drisw_glx.c:435)
==767499== by 0x5A36CC2: MakeContextCurrent (glxcurrent.c:220)
==767499== by 0x5A36DF9: glXMakeCurrent (glxcurrent.c:253)
==767499== by 0x531849C: InternalMakeCurrentVendor (libglx.c:875)
==767499== by 0x53185C3: InternalMakeCurrentDispatch (libglx.c:930)
==767499== by 0x5318DE5: CommonMakeCurrent (libglx.c:1074)
==767499== by 0x5318ED5: glXMakeCurrent (libglx.c:1119)
==767499== by 0x4AA9CFA: glXMakeCurrent (g_libglglxwrapper.c:930)
==767499== by 0x4D5AA36: ??? (in /usr/lib64/libwaffle-1.so.0.6.1)
==767499== by 0x4D5E16E: waffle_make_current (in /usr/lib64/libwaffle-1.so.0.6.1)
==767499== by 0x499C8CD: wfl_checked_make_current (piglit-util-waffle.h:115)
==767499== by 0x499DA04: make_context_current_singlepass (piglit_wfl_framework.c:488)
==767499== by 0x499DC43: make_context_current (piglit_wfl_framework.c:565)
==767499== by 0x499DD88: piglit_wfl_framework_init (piglit_wfl_framework.c:628)
==767499== by 0x499E3FC: piglit_winsys_framework_init (piglit_winsys_framework.c:209)
==767499== by 0x499F581: piglit_x11_framework_create (piglit_x11_framework.c:229)
==767499== by 0x499E361: piglit_winsys_framework_factory (piglit_winsys_framework.c:175)
==767499== by 0x498CA60: piglit_gl_framework_factory (piglit_gl_framework.c:53)
==767499== by 0x498C587: piglit_gl_test_run (piglit-framework-gl.c:221)
==767499== by 0x4022B4: main (primitive-restart.c:45)
Fixes: b5c390c113 ("vulkan/wsi: add support for detecting mit-shm pixmaps.")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13124>
The vk_shader_module_handle_from_nir() macro was constructing a
temporary vk_shader_module and passing it through
vk_shader_module_to_handle(). Since this is a function and not a macro,
it means that the lifetime of the temporary vk_shader_module will end
once the to_handle() function is called. Technically, this is a
use-after-free. I really don't know why no one has been bitten by this
yet....
Fixes: a41e98ddca "vk/util: add a util macro for initializing stack..."
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13101>
This is boilerplate that drivers have to replicate, so make a nice helper.
The feature/property macro lists are are copy and pasted from anv, though
the helper functions has been split between 1.1 and 1.2 (and thus the macros
refactored).
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12967>
Commit 0245b825 switched from returning the error code VK_ERROR_OUT_OF_DATE_KHR
to returning the success code VK_SUBOPTIMAL_KHR. Prior to that commit, the error
code caused all code paths to fail immediately, but the success code does not.
Currently the success code is not recorded in some scenarios, resulting in a
result of VK_SUCCESS instead. This breaks applications that rely on the
result (per the spec) to trigger resizes.
This commit ensures that the proper VK_SUBOPTIMAL_KHR success code is set as a
sticky status (as comments indicate was intended), ensuring that it is
propagated to user code.
Fixes#5331
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12782>
By default, Mesa's X11 Vulkan WSI will wait for buffers to be ready
before submitting them to Xwayland when the swapchain is created
with the IMMEDIATE mode.
This is undesirable when the Wayland compositor already monitors
fences. A Wayland compositor may want to know the delay between
the buffer submition and the end of the GPU work, this is impossible
to measure if the WSI waits for the buffer to be ready before
submission.
Since most compositors don't monitor fences, let's introduce a driconf
option for this for now. We can reconsider once more compositors
have better support for fences.
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11290>
With hw devices, when you submit a present, implicit sync will
make sure the work submitted to the gpu on the client will end
up happening before the present work submitted on the server.
However with sw paths there is no real GPU, the lavapipe fake
GPU thread is client side only and presenting is done directly
from the pixmap (or later shared pixmap). In order for this to
make sense the wsi common code should wait for the fence on the
image before queueing the submit to the server so that all
client works has been flushed to the pixmap before the copy or
present operation is submitted.
Fixes: 8004fa9c95 ("vulkan/wsi: add sw support. (v2)")
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12502>
struct wsi_wl_image is only used as member of the swapchain, and during
the swapchain creation the image is already initialized to zero. So we
have no problems with members of the image being used uninitialized.
But for consistency, memset the members of this struct to zero in
wsi_wl_image_init(). This can help to avoid problems in the future.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12451>
Jason Ekstrand