We need to support this if we advertise KHR_swapchain_maintenance1
Cc: mesa-stable
Signed-off-by: llyyr <llyyr.public@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
(cherry picked from commit c3763b12e2)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39462>
Similar to last MR, since we advertise support for
KHR_swapchain_maintenance1, we need to advertise this
Cc: mesa-stable
Signed-off-by: llyyr <llyyr.public@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
(cherry picked from commit a1dd7eec87)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39462>
It is not actually available to all the platforms mesa can be compiled
to, so let's keep an opt-in list of supported platforms instead, and
compile it out on all other platforms.
Fixes: 48a0478126 ("zink: add renderdoc handling")
(cherry picked from commit 93390d4b73)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39462>
There are cases like zink where we have a file descriptors we are searching
for devices for, so we don't need device selecting reordering, we just want
the fastest path to get the devices so we can match them.
This also helps avoid some cases of deadlock inside compositors where
zink/vulkan initialises later and tries to connect to the compositor.
This uses a VK_EXT_layer_setting to add a bypass setting.
Cc: mesa-stable
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
(cherry picked from commit 833706e381)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39462>
Currently the image creation failure handling codepath of
wsi_headless_surface_create_swapchain() just calls
wsi_headless_swapchain_destroy() , which will try to destroy all
`image_count` of images. However, some of these images might never be
successfully created because of the failure, which leads to double-free.
Set image_count to the number of successfully created images before
calling wsi_headless_swapchin_destroy() to prevent over-destroying.
Fixes dEQP-VK.wsi.headless.swapchain.simulate_oom.* on lavapipe and pvr,
although some of the tests got QualityWarning saying "Creating swapchain
did not succeed, callback limit exceeded" on lavapipe (Pass on pvr).
Cc: mesa-stable
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
(cherry picked from commit e8c81652c9)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39462>
Since we use atomic mode setting now, the wsi->fd we use needs to have
the atomic client cap.
There are several different code paths where wsi can acquire a file
descriptor. For drm masters, the atomic client cap is set in
wsi_display_init_wsi. For leased drm fds, there are AcquireDrmDisplayEXT
and AcquireXlibDisplayEXT.
According to a comment we previously assumed wsi_display_get_connector
is common among all code paths, and that's why the atomic client cap was
set there. But that assumption can be broken based on the particular
order which the application invokes vulkan APIs in.
This commit simply push the drmSetClientCap to all entrypoints where a
drm fd comes through.
Fixes: 513ffea1d3 ("wsi/display: use atomic mode setting")
Signed-off-by: Yuxuan Shui <yshui@codeweavers.com>
(cherry picked from commit e0fbf9a908)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39117>
Shader objects are by definition I think independents.
But implementation like Anv would like to optimize dynamic descriptors
if possible. It's possible if the sets are not independent.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
(cherry picked from commit 104206fb0f)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39003>
Dynamic descriptors are mapped an array of offsets provided through
vkCmdBindDescriptorSets*() commands.
When pipelines are compiled with independent sets layouts, the
implementation might have to do additional runtime calculation to
figure out what offset in the contiguous array maps to what dynamic
descriptor in the pipeline layout.
For graphics pipelines you can always compute that information when
binding the shaders. There is always a limited amount of shaders (5
max).
For ray tracing pipelines, there could be lots of shaders to process
at every pipeline binding call. Besides there is no interface from the
runtime to the driver to list all the shaders used at the moment.
So do that tracking in the runtime and pass the information down to
the driver through the cmd_set_rt_state() vfunc.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 69a04151db ("vulkan/runtime: add ray tracing pipeline support")
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
(cherry picked from commit 5c53c6e693)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38803>
In the WAIT_ALL case in spin_wait_for_sync_file(), we were returning the
moment we saw the first success. However, this isn't a wait-all, it's a
bad wait-any. We should instead just continue on to check the next sync
until we've ensured that every sync in the array has a sync file. The
only reason this wasn't blowing up in our face is because it only
affects non-timeline drivers (pretty rare these days) and because most
of the places where we use WAIT_PENDING on non-timeline drivers is to
guard a sync file export and those typically have only a single sync in
the array.
Cc: mesa-stable
Reviewed-by: Gurchetan Singh <gurchetansingh@google.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
(cherry picked from commit e4e619d685)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38803>
Without these fixes, H.265 streams using long-term references would
fail to decode correctly as the decoder wouldn't distinguish between
short-term and long-term reference frames.
Fixes: 896f95a37e ("vulkan/video: fix h265 decoding with LT enabled.")
Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 01de6ac134)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38803>
GTK is missing a semaphore between QueueSubmit() and QueuePresent()
causing the WSI submit to be "unordered" and to immediately signal the
semaphores (because it's missing a wait semaphore in QueuePresent()).
The workaround is to disable unordered WSI submits until GTK fixes it
properly.
Cc: "25.3"
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14087
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 0d9d45db4e)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38432>
CTA-861-G section 6.9.1 Static Metadata Type 1 declares that zero values
for different groups of HDR Metadata properties are allowed, including
zero nits values for max display mastering luminance, max content light
level, max frame-average light level and min display mastering luminance.
A zero value is meant to be treated by the video sink as "undefined" /
"unknown", and handled accordingly. This is common for dynamically
generated visual content.
The is_hdr_metadata_legal() function in the Vulkan/WSI/Wayland HDR backend
currently declares HDR light level metadata as invalid if the mastering
display min_luminance and max_luminance light levels are set to the legal
level of zero nits. This causes valid HDR metadata as set by the client
via vkSetHdrMetadata() to be not sent to the compositor.
Fix this by skipping checks that don't apply if min_luminance or
max_luminance are zero. If max_luminance is zero then we skip sending
of mastering display min/max luminance to Wayland, as sending a a
max_luminance <= min_luminance would trigger a protocol error. All
other valid data is still send, ie. color primaries, white-point,
content light levels.
Fixes: cb7726bb2c ("vulkan/wsi: validate HDR metadata to not cause protocol errors")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Co-authored-by: Michel Dänzer <michel@daenzer.net>
Reviewed-by: Xaver Hugl <xaver.hugl@kde.org>
(cherry picked from commit 490f05f82c)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38432>
At least some drivers need a full modeset to change the Colorspace
property or to en-/disable HDR mode. E.g., at least amdgpu-kms as
tested under Linux 6.8 on Polaris needs it. Otherwise the atomic
commit for disabling HDR in _wsi_display_cleanup_state() will fail,
and the connector stays stuck in HDR mode after vkDestroySwapchainKHR().
Fixes: 1ed78dd7ec ("wsi/display: Clean up DRM hdr/color state on swapchain destruction")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Autumn Ashton <misyl@froggi.es>
(cherry picked from commit ba82d36dce)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38432>
For a selected non-default imageColorSpace during swapchain creation,
make sure that proper HDR setup also works even if a client app does not
explicitly call vkSetHdrMetadataEXT() in time.
Assign the EDID provided metadata here, so the 1st atomic commit will
set Colorspace and HDR metadata properties on the connector, to make sure
HDR or other wide color gamut modes get enabled.
Without this, the chain->color_outcome_serial would stay at zero and
the properties would not ever get assigned during drm_atomic_commit(),
leaving HDR disabled on the display sink.
Fixes: 13137393f6 ("wsi/display: Expose HDR10 colorspace based on EDID")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Autumn Ashton <misyl@froggi.es>
(cherry picked from commit 19b2e3b81b)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38432>
CTA-861-G section 6.9.1 Static Metadata Type 1 declares that zero values
for different groups of HDR Metadata properties are allowed, including
zero nits values for max display mastering luminance, max content light
level, max frame-average light level and min display mastering luminance.
A zero value is meant to be treated by the video sink as "undefined" /
"unknown", and handled accordingly. This is common for dynamically
generated visual content.
Therefore don't assert on some minimum nits level > 0, but only check for
a non-negative level.
Fixes: b4176393a0 ("wsi/display: Implement VK_EXT_hdr_metadata on KHR_display swapchain")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Autumn Ashton <misyl@froggi.es>
(cherry picked from commit 19dc09aded)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38432>
We're doing the same in vk_pipeline_precomp_shader_create().
Also fixes valgrind warning due to uninitialized fields
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
(cherry picked from commit fc6d17a290)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38432>
Always copy parameters that are not guarded by a flag, zero init
the structs if not provided by application.
Fixes vk_layer_validation_tests PositiveVideoEncode*.GetEncodedSessionParams
Cc: mesa-stable
Reviewed-by: Benjamin Cheng <benjamin.cheng@amd.com>
(cherry picked from commit 6a1c6ab95b)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38432>
If renderpass has D/S attachment, but pipeline has D/S as UNDEFINED,
D/S should be properly disabled for the pipeline. The easiest way is to
ensure that D/S state is valid when pipeline's D/S format is UNDEFINED.
So we always create VkPipelineDepthStencilStateCreateInfo.
CC: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
(cherry picked from commit 2798ef7bfd)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38268>
It's not really clear whether or not it should use gamma 2.2 or the piece-wise
transfer function, or how clients would use it for wider gamut in general.
Currently no compositors I know of support ext_srgb, so this shouldn't affect
applications in practice.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Fixes: 4b663d56 ("vulkan/wsi: implement support for VK_EXT_hdr_metadata on Wayland")
(cherry picked from commit 14fcf145e3)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38167>
This reverts commit a219308867.
It's failing most of the tests on Anv :
$ ./deqp-vk -n dEQP-VK.wsi.xlib.maintenance1.scaling.*
Test run totals:
Passed: 88/2422 (3.6%)
Failed: 576/2422 (23.8%)
Not supported: 1758/2422 (72.6%)
Warnings: 0/2422 (0.0%)
Waived: 0/2422 (0.0%)
The only passing tests seem to be with this pattern :
dEQP-VK.wsi.xlib.maintenance1.scaling.*.same_size_and_aspect
(cherry picked from commit 2baa3b8c06)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38010>
This was something that came up in the slop MR. Not sure it's actually a
good idea or not but kind of curious what people think, given we have a
sound tool (Coccinelle) to do the transform. Saves a redundant branch
but means extra noninlined function calls.. likely no actual perf impact
but saves some code.
Via Coccinelle patches:
@@
expression ptr;
@@
-if (ptr) {
-free(ptr);
-}
+free(ptr);
@@
expression ptr;
@@
-if (ptr) {
-FREE(ptr);
-}
+FREE(ptr);
@@
expression ptr;
@@
-if (ptr) {
-ralloc_free(ptr);
-}
+ralloc_free(ptr);
@@
expression ptr;
@@
-if (ptr != NULL) {
-free(ptr);
-}
-
+free(ptr);
@@
expression ptr;
@@
-if (ptr != NULL) {
-FREE(ptr);
-}
-
+FREE(ptr);
@@
expression ptr;
@@
-if (ptr != NULL) {
-ralloc_free(ptr);
-}
-
+ralloc_free(ptr);
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> [v3d]
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> [venus]
Reviewed-by: Frank Binns <frank.binns@imgtec.com> [powervr]
Reviewed-by: Janne Grunau <j@jannau.net> [asahi]
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> [radv]
Reviewed-by: Job Noorman <jnoorman@igalia.com> [ir3]
Acked-by: Marek Olšák <maraeo@gmail.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Job Noorman <jnoorman@igalia.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37892>
Monado calls vkGetRandROutputDisplayEXT, which calls wsi_display_get_output, which then calls
wsi_display_alloc_connector with fd = wsi->fd, which at this point is still -1 as the display is not leased yet.
Signed-off-by: Torge Matthies <openglfreak@googlemail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36325>
Drivers need to track which feedback bits were set at creation time to
output the correct things in vkGetQueryPoolResults().
Cc: mesa-stable
Reviewed-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37774>
These are no longer used anywhere. Moreover, it's not clear that they
can be used for a correct implementation of pipeline barriers since a
correct implementation cannot ignore execution deps in non-shader
stages.
Reviewed-by: Mary Guillemard <mary@mary.zone>
Reviewed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37671>
As noted, the flag we allocate with controls whether *anyone* can implicit
sync on the BO through amdgpu interfaces, not just whether our fd does.
This restores radv to the behavior before the regressing commit.
Fixes: 4dcf32c56e ("wsi/drm: Don't request implicit sync if we're doing implicit sync ourselves.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37772>
Adding vk_enum_defines.h to idep_vulkan_util_headers to help
ninja-to-soong generate correct rules for the Android build system.
Without it, ninja-to-soong is not able to figure out that this file is
needed by targets depending on idep_vulkan_util_headers, leading to
build errors with the file missing.
Ref #14072
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37789>
Usage of '--outdir' argument in python scripts makes it very
complicated for tools like ninja-to-soong to generate the Android
equivalent build file.
This is because the option is less clear on what will be generated.
Instead, change it for '--out' where we give the full path of the file
to generate. This has the good point of deduplicating the locations of
the file name to have it only in 'meson.build'.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37741>
