After commit "vulkan: don't destroy vk_sync_timeline if a point is
still pending", dEQP-VK.synchronization*.timeline_semaphore.* is
no longer hurting other tests.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35921>
Currently, vk_sync_timeline_wait() may report idle while we still have
time points outstanding in vk_queue. This race between vk_sync_timeline
and vk_queue is problematic as vk_queue_submit_cleanup() can end-up
trying to unref a timeline point that was already destroyed in
vk_sync_timeline_finish(), leading to an use-after-free.
Address this race-condition by introducing a reference counter to the
timeline. Each timeline point takes a reference to the timeline when
it's checked out and drops the reference when it's freed. Now, the
timeline is only destroyed when all the references had been dropped.
To guarantee that all references will be dropped and the timeline will
be destroyed, vk_sync_timeline_finish() waits for all pending points
to be checked out.
This commit fixes several Mesa CI flakes in v3dv related to timeline
semaphores.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12648
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35921>
Previously, we had a sort of double reference count with refcount being
used to track how many waits were holding a reference and pending being
used to track whether or not it was in the pending list. This meant
that the unref operation actually had to look at both refcount and
pending in order to determine if it could free the time point. This is
way too confusing. Instead, we should just always take a reference
while we're pending.
This also simplifies the over-all interface because there's no longer a
difference between free and release. `struct vk_sync_timeline_point` is
now just a reference-counted API.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35921>
Whenever we assume the timeline state is locked, we use _locked, pass in
the timeline state explicitly, and rename it so it's clearly an action
which the timeline does on the point. This makes it far more clear who
owns a reference to what and where.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35921>
The lifetime of `struct vk_sync_timeline` is tied to the lifetime of
`vk_fence` or `vk_semaphore` objects. To better manage this lifecycle,
create a wrapper struct `vk_sync_timeline_state` that contains the
timeline state and is dynamically allocated when the timeline is
initialized. This separation allows the timeline state to persist
independently of the sync object lifecycle.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35921>
This creates a concept of "peripheral" for Rust crates housed in
Mesa, and "unofficially" uploaded to crates.io by subcommunities
of Mesa. This is modeled on LLVM's peripheral versus core
support concept:
https://llvm.org/docs/SupportPolicy.html
This allows use of the mesa3d_util crate without vendoring it.
This is a desire of the crosvm maintainers (crrev.com/c/6594760).
This also formally defines CODEOWNERS to be the projected uploaders
of the mesa3d_util crate. Everyone of course is encouraged to make
changes, but that just gives us a heads-up to update the downstream
imports of mesa3d_util.
The Cargo.toml file is not added here, since Meson is the only
officially supported build system of the Mesa3D project.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36276>
The header says:
enum ADataSpace AHardwareBuffer_getDataSpace(const AHardwareBuffer* _Nonnull buffer)
__INTRODUCED_IN(__ANDROID_API_V__);
which is API level 35.
Reviewed-by: Jason Macnak <jmacnak@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36338>
`bm-init.sh` executes `init-stage1.sh` and then an `export`, but the
latter command overwrite the exit code `$?`, so we need to put the first
exit code into a variable.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36356>
This traces back to c688f8f8c5, but the
shape of the fix would be different if against that. So we do the
optimal for the current code flow and only port to stable.
Cc: mesa-stable
Reviewed-by: Lucas Fryzek <lfryzek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36335>
Add lvp_image_bind helper so that bind status is robustly handled
outside the core bind, which simplifies the exit paths. Meanwhile, the
spec doesn't require to proceed binding of image internal planes if a
prior plane binding has failed. So this change further simplifies the
non-disjoint image binding result handling.
Reviewed-by: Lucas Fryzek <lfryzek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36335>
Per spec of VkBindImageMemorySwapchainInfoKHR:
> If swapchain is not NULL, the swapchain and imageIndex are used to
determine the memory that the image is bound to, instead of memory and
memoryOffset.
Meanwhile, common wsi is doing dedicated allocation for swapchain image
memory, so it's required to use zero memoryOffset by the spec. Then here
we can safely set to zero memoryOffset before passing to the actual
binding call.
In practice, when the struct is initialized with proper sType and memory
being VK_NULL_HANDLE, the memoryOffset is most likely left being zero
initialized. Not a critical must fix but still a bug.
Fixes: ace49d9e52 ("lavapipe: adopt wsi_common_get_memory")
Reviewed-by: Lucas Fryzek <lfryzek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36335>
Set to true everywhere except:
- spirv_to_nir used by Vulkan
- bindless handles in GLSL
- some internal shaders and driver-specific code
Acked-by: Job Noorman <job@noorman.info>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36099>
We have a lot of pattern like this on Valhall:
FCMP_OR.f32.lt.m1 r28, ^r28, r27, 0x0
FCMP_OR.f32.lt.m1 r29, r27, r25, 0x0
LSHIFT_AND.i32 r28, ^r28, 0x0.b00, ^r29
That can be simplified into:
FCMP_OR.f32.lt.m1 r29, r27, r25, 0x0
FCMP_AND.f32.lt.m1 r28, ^r28, r27, ^r29
This pass merge those specific cases while setting the appropriate
logical variant of the CMP instruction.
We do not try to merge the srcs that do not originate from a matching CMP
instruction with matching result type as the logical operation is
performed before the result type transformation.
Now this is enough to optimise a lot of common cases anyway so it is
still a win.
Results on fossils/sascha-willems:
Totals:
Instrs: 42157 -> 42059 (-0.23%)
CodeSize: 582784 -> 581760 (-0.18%)
Estimated normalized SFU cycles: 159.9375 -> 153.75 (-3.87%)
Totals from 13 (2.07% of 627) affected shaders:
Instrs: 3490 -> 3392 (-2.81%)
CodeSize: 29696 -> 28672 (-3.45%)
Estimated normalized SFU cycles: 15.8125 -> 9.625 (-39.13%)
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36327>
Place the convention so that distro packagers know that they can
rely on it, and not following it is a bug.
This is the same convention that Meson uses for Cargo subprojects,
but Mesa is not using them as they are experimental and not really
usable yet.
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36284>
Use the convention for Rust subprojects that was adopted by Meson 1.5.0
and newer.
Distros would prefer to avoid vendored crate sources, and instead use
local sources from e.g. /usr/share/cargo/registry. While Meson does not
support a local registry, it can be emulated with MESON_PACKAGE_CACHE_DIR.
However, because the distro might not be using the exact version of the
package, but only one that has the same semver, packagers need to add
some hacks to rewrite the wrap files. For example, in Fedora:
export MESON_PACKAGE_CACHE_DIR="%{cargo_registry}/"
# So... Meson can't actually find them without tweaks
%define inst_crate_nameversion() %(basename %{cargo_registry}/%{1}-*)
%define rewrite_wrap_file() sed -e "/source.*/d" -e "s/%{1}-.*/%{inst_crate_nameversion %{1}}/" -i subprojects/%{1}.wrap
%rewrite_wrap_file proc-macro2
%rewrite_wrap_file quote
%rewrite_wrap_file syn
%rewrite_wrap_file unicode-ident
%rewrite_wrap_file paste
Having a common convention for the name of Rust wraps makes it possible
to perform this transformation with a script without listing
the wraps one by one, and to share the script across multiple packages
(which will be useful when QEMU starts using Rust in a similar way to Mesa).
For an example of such a script, see
https://lore.kernel.org/r/20250722083507.678542-1-pbonzini@redhat.com/.
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36284>
In the dri3_handle_present_event() function, it uses an event enum
and two macros. So I suggest to change these all to use enums for
consistency.
Signed-off-by: Luc Ma <luc@sietium.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30461>
information
This information (otherwise invisible to the guest) may be used in the
future in some other guest-only functionality
Reviewed-by: Gurchetan Singh <gurchetansingh@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36330>
... in GfxstreamConnectionManager, to acquire the threadLocalInstance
of the connectionManager. Using thread_local attribute storage to store
some CPP primitives (i.e. unique_ptr) can cause issues on some
platforms.
Better to do all TLS as explicit as possible, using the available
utilities from common src/util. Don't need to wrap it in
a std::unique_ptr either, as the instance is just managed by the
destructor in the TLS interface.
Reviewed-by: Gurchetan Singh <gurchetansingh@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36302>
Drop the custom fluster-runner.sh script and add a deqp-runner suite for
the `radeonsi-raven-vaapi-fluster` job.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36316>
The compiled image function is derived from the image view, which is
supposed to match what is declared in the shader, however we did fixups
for array targets that only had one layer, since pipe_shader_image
actually doesn't have a target (derived from the resource instead).
But this is not correct at least for vulkan, since then the layer
coord is completely ignored, so we never got OOB behavior wrt the
layer coord.
Use single_layer_view field in pipe_shader_image to denote non-array
targets (the GL state tracker uses this in a similar way already,
although llvmpipe ignored it).
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36304>
As we are already updating tmu_dirty_rcl based on the the
shader usage of tmu writes at v3d_emit_gl_shader_state we
can avoid setting it everytime we have a SSBO or image
attached.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36343>
Allows detecting if the queue ends up going idle due to
a cross-queue dependency. Since we're only considering delays from
specific queues, we would not be able to detect low-latency situations
arising from the start of a frame happening on async queues.
Until we observe real work happening for a queue in a frame context,
submit timestamps ahead of any other waits.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34242>
VkLayer_MESA_anti_lag is a lightweight implicit layer which provides
an open-source implementation of the VK_AMD_anti_lag vulkan extension.
The algorithm used by this layer is very simplistic and only aims to
minimize the delay between calls to vkQueueSubmit or vkQueueSubmit2
and the begin of the execution of the submission.
In order to build VkLayer_MESA_anti_lag, pass -Dlayers=anti-lag to meson.
It is possible to either install the layer or to use
VK_ADD_IMPLICIT_LAYER_PATH=<buildpath>/share/vulkan/implicit_layer.d/
for testing purposes.
(Keep in mind that you have to adjust the library_path in the json file in that case.)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34242>
Replace incorrect MIN2 clamping with proper 5.8 signed fixed point
encoding. The hardware expects LOD values in 5.8 format with a range
of -16.0 to +15.99609375. Clamp input values to this valid range
before conversion to handle overflow correctly.
Passes dEQP-GLES3.functional.texture.mipmap.*.max_lod.* on GC7000.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36303>
