The option's description is:
> Whether to use LLVM for the Gallium draw module, if LLVM is included.
Let's disable it right away if LLVM is disabled, to avoid some
configurations from failing.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38558>
(cherry picked from commit 37c7d19e46)
The versioning scheme changed in v45.0 (the previous version was
3.48.0). As such, this version check would wrongly accept e.g. 48.0.
Fixes: e9341568fa ("meson: require sysprof-capture-4 >= 4.49.0")
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38557>
(cherry picked from commit ad14942300)
Commit 2aaa6ebb "build/amd: add amd-use-llvm build option"
allows to build radeonsi and radv without LLVM dependency
so LLVM constraint is applicable when amd-use-llvm=true
Fixes: 82047fa8 ("amd: drop support for LLVM 15, 16, 17")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37695>
(cherry picked from commit dd2476a257)
The current -fmacro-prefix-map only handles removal of relative paths
but we still need to handle absolute paths.
The following path can be found in libvulkan_panfrost.so when building
with Yocto for example:
/work/build/tmp/work/cortexa76-cortexa55-crypto-poky-linux/mesa/25.2.0/sources/mesa-25.2.0/src/panfrost/libpan/../../util/bitpack_helpers.h
These paths currently seem to only appear in the binary in strings that
start with "Shader assertion fail at " which seems to indicate there are
calls to assert() with absolute paths as well as relative paths (which
are already patched with fmacro-prefix-map).
By stripping the project source and build root directories from the
paths with -fmacro-prefix-map, we get rid of this reproducibility issue
(which incidentally makes the build fail due to buildpaths QA issue).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36927>
(cherry picked from commit b1a28b1165)
Starting with version 1.8, libX11 calls XInitThreads() from the library
constructor so we can just assume we always have threaded X11.
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36123>
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>
DRI2 was hidden behind a legacy-x11 build option back in the 24.2
release. It's now been a year, so let's get on with removing it so we
can simplify our winsys interactions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35885>
This isn't a huge cleanup on its own, but it lets us start assuming
coroutine support, and I would like to unify graphics shader dispatch
to work the same way as compute shader dispatch.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35374>
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>
for various math helpers.
the clzll version isn't available since long long is 128-bit for CL.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35639>
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>
If it compiles, it works. And there's not a particularly good reason to
disable it, so don't let people disable it.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34239>
