Previously, if neither packaging.version or distutils.version is present
in the environment the has_mako check would return non-zero exit code
and meson would print that mako is required which is misleading since
mako can be in the environment but not packaging or distutils. This can
happen for Python>=3.12 where distutils is no longer in the Python
stdlib but provided externally by setuptools.
Signed-off-by: bbhtt <bbhtt.zn0i8@slmail.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36697>
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>
Similar to how support for X11's DRI2 protocol was deprecated in 24.2,
begin deprecating EGL_WL_bind_wayland_display (including
eglBindWaylandDisplayWL et al) by moving it behind a legacy-wayland
build option.
This extension was originally created in a pre-dmabuf world, where we
didn't have a universally-accepted way of exchanging buffers between
client and compositor, or even really the ability to describe formats
and modifiers universally.
Since then, the world has settled on dmabuf with DRM FourCC and
modifiers. We've had the zwp_linux_dmabuf_v1 protocol for 10 years now:
both clients and compositors implement this protocol to handle buffer
sharing. Compositors either use EGL_EXT_image_dma_buf_import or the
Vulkan dmabuf extensions to import these into GPU world.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36026>
This allows us to get better error messages in cases where LLVM has been
explicitly disabled but not found, as well making use of the feature
object for the required argument to dependency. This in turn can give
better error messages when the object is used incorrectly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35840>
In Meson 1.8 the b_sanitize option was changed from an enumerated set of
known sanitizers to an array of options to test with `-fsanitize`, this
means that the thread sanitizer could be used in conjunction with one
or more other sanitizers and we need to account for this. Use
`.contains()` to check if `thread` is in the sanitizer list
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35747>
Will be used by Cuttlefish CI/CD, but also commonly used by
gfxstream developers.
meson setup gfxstream-build -Dvulkan-drivers="gfxstream" -Dgallium-drivers="" -Dvirtgpu_kumquat=true -Dopengl=false -Drust_std=2021
In distros, virtgpu_kumquat is not expected to be packaged since
it is a CI/CD tool.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35210>
Meson 1.7.0 is required to ensure that generated bindings
are suitable for use with the selected Rust compiler.
Bindgen is bumped to 0.71.1 which has more permissive handling of
`--rust-target`, enabling (almost) any valid Rust version to be
passed as a target; `-nightly` and `-beta*` suffixes are an exception
to this.
This behaviour is expected to improve further with later versions of
Meson; upstream fixes have landed that:
- pass a stripped version string to bindgen
- additionally pass an appropriate `--rust-edition` if `rust_std` is
set (or "nightly" if the compiler is `nightly`).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12680
Bug: https://bugs.gentoo.org/946913
Signed-off-by: Matt Jolly <kangie@gentoo.org>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33725>
This allows building Mesa with the Android NDK, which doesn't provide
libdrm.
We will generate an `Android.bp` file using the `ninja-to-soong` tool
(https://github.com/rjodinchr/ninja-to-soong), and to do this we run
Mesa's standard meson build system to generate the ninja commands that
we then translate to soong.
That meson invocation is done using the Android NDK, which doesn't
provide libdrm, so until we find an alternative solution[*] we provide a
wrap file that builds libdrm as part of the Mesa build (but does not
install it--we still use the Android-provided libdrm at runtime)
Co-authored-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35058>
there comes a time when a project has to be declared unfit to remain
in the tree
this frontend hasn't seen actual development in about 6 years
if someone has a pressing need to continue development, there's no
blocker to un-deleting it, but unless that happens, there's now a
more featureful, more conformant, more active CL frontend in the tree
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19385>
Yiwei Zhang