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>
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>
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>
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 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>
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>
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>
