It appears to be possible that IDLE is observed before COMPLETE.
In this case, an application may access present_id in subsequent
QueuePresentKHR and race against the fence worker reading present_id.
Solve this by adding a separate signal_present_id that is used when
completing to avoid the race.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22633>
To implement some of the features of the layer, we need to enable some
of the feature bits at device/command_buffer creation. To do so, we
need to edit some of the structures coming from the application. Most
of those are const so we need to clone them before edition.
This change disables some of the layer features if we run into a
situation where one of the structure we need to clone is unknown such
that we can't make a copy of it (since we don't know its size).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7677
Cc: mesa-stable
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19897>
Anv is trying to rely on the stages put into the library graphics
state.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22460>
ms.sample_mask is only 16b, while VkSampleMask is 32b and it is allowed
to have all of them set even if maximum 16 samples are supported.
E.g. happens with Zink running supertuxkart:
supertuxkart: ../../../source/mesa/src/vulkan/runtime/vk_graphics_state.c:2346: vk_common_CmdSetSampleMaskEXT: Assertion `(dyn)->ms.sample_mask == (*pSampleMask)' failed.
vk_common_CmdSetSampleMaskEXT (commandBuffer=0x5556e903f0, samples=VK_SAMPLE_COUNT_1_BIT, pSampleMask=0x5556819ccc) at vk_graphics_state.c:2346
zink_draw<(zink_multidraw)1, (zink_dynamic_state)5, true, false> (...) at zink_draw.cpp:639
zink_draw_vbo<(zink_multidraw)1, (zink_dynamic_state)5, true> (...) at zink_draw.cpp:922
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22360>
Needed to correctly implement GetPhysicalDeviceFormatProperties2.
Cc stable so the turnip patch can get backported cleanly.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22217>
the spec for vkGetDrmDisplayEXT says:
"If there is no VkDisplayKHR corresponding to the connectorId on the
physicalDevice, the returning display must be set to VK_NULL_HANDLE.
The provided drmFd must correspond to the one owned by the physicalDevice.
If not, the error code VK_ERROR_UNKNOWN must be returned. (...)
The given connectorId must be a resource owned by the provided drmFd.
If not, the error code VK_ERROR_UNKNOWN must be returned"
We were only setting the display pointer to VK_NULL_HANDLE if the provided
drmFd was valid, however, there are CTS tests checking that it is also set
to NULL when it is not.
Fixes the following test on all drivers exposing EXT_acquire_drm_display
(tested with Intel and V3DV):
dEQP-VK.wsi.acquire_drm_display.acquire_drm_display_invalid_fd
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22283>
ANV was the only driver using them and now it's on feedback loop flags.
Other drivers should convert instead of depending on the old version.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22191>
This records any rendering pipeline flags in the render pass. This
provides much-needed information for the VK_KHR_fragment_shading_rate
and VK_EXT_fragment_density_map extensions as well as provides an
alternative to VkRenderingSelfDependencyInfoMESA which is based on
VK_EXT_attachment_feedback_loop_layout.
v2 (Connor): Name something more general
v3 (Faith): Also add the FSR flag
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22191>
This lets us provide a vk_device_memory_range helper similar to what's
provided for buffers for dealing with VK_WHOLE_SIZE. We can also handle
flags and some annoyance around Android hardware buffer import.
Reviewed-by: Lina Versace <lina@kiwitree.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22038>
Before GCC 11.2 initializing anonymous struct with extensions gave:
error: too many initializers for 'vk_device_extension_table'
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21931>
