We generate a lot of functions without knowing if they end up being used
or not. So we can't easily avoid these warnings.
This fixes a bunch of warnings for me when building with Clang.
Acked-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15547>
This is for compatibility with loaders that don't know about
__DRI_DRIVER_GET_EXTENSIONS. xserver has supported that since 1.15.0,
which is almost nine years old now.
While we're about it, fix a comment in meson.build that used to be about
megadrivers to reflect reality.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15649>
This is Dozen, the Vulkan on DirectX 12 driver. Not to be confused with
DirectEggs.
This is an early prototype, and not meant to be upstreamed as-is.
Co-Authored-by: Boris Brezillon <boris.brezillon@collabora.com>
Co-Authored-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Co-Authored-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Co-Authored-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14766>
Add a new backend to enable using native driver in a VM guest, via a new
virtgpu context type which (indirectly) makes host kernel interface
available in guest and handles the details of mapping buffers to guest,
etc.
Note that fence-fd's are currently a bit awkward, in that they get
signaled by the guest kernel driver (drm/virtio) once virglrenderer in
the host has processed the execbuf, not when host kernel has signaled
the submit fence. For passing buffers to the host (virtio-wl) the egl
context in virglrenderer is used to create a fence on the host side.
But use of out-fence-fd's in guest could have slightly unexpected
results. For this reason we limit all submitqueues to default priority
(so they cannot be preepmted by host egl context). AFAICT virgl and
venus have a similar problem, which will eventually be solveable once we
have RESOURCE_CREATE_SYNC.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14900>
This matches the behavior of e.g. panfrost's bifrost_compiler target.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15284>
Rename MESA_GLSL_CACHE to MESA_SHADER_CACHE, as the on-disk cache can
store not only GLSL but also SPIR-V shaders.
v2:
- Keep old envvar as deprecated (Mike)
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15390>
For the new AMDGPU CTX OP stable pstates.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14038>
Meson devenv is a feature added in meson 0.58 (thus the features is
version guarded) that allows creating a shell environment with
environment variables automatically setup for running the project inside
the build dir. Some variables (such as LD_LIBRARY_PATH and PATH) are set
automatically, others must be added by the project.
For vulkan is is relativley simple, we create a new, uninstalled, icd
file for each driver and set the VK_ICD_FILENAMES variable
appropriately. This can be used with:
```sh
meson devenv -C $builddir
```
then, vulkan applications will automatically use the uninstall vulkan
driver, no need to install.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14826>
For GL, we disable the dlclose() call on the driver in asan builds so that
leak reports get proper backtraces. For Vulkan, the dlclose() happens
from libvulkan so you need a bigger hammer to keep our drivers loaded.
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14235>
If we don't do this, and we are statically linking LLVM
(-Dshared-llvm=disabled) while using a version of LLVM compiled for a
general-purpose distribution, then the link fails with undefined
references to the functions called by LLVMInitializeAllTargets().
Using a version of LLVM that was built specifically for Mesa will
sometimes mask this: if the only backends built into LLVM are backends
that we specifically link anyway, then the link will succeed.
According to commit 80817b6e "meson: Adjust Clover's required LLVM
modules", all-targets is not available when using CMake to locate LLVM,
so make it optional rather than mandatory.
This partially reverts commit 80817b6e34.
Resolves: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3962
Resolves: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5609
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13720>
run_command will change the default for the check arg to true
in the future. If it is true then meson will exit if the command
fails. It must be false here as we check the return code to
provide a meaningful error message.
With meson 0.61 we get the following warning:
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14602>
For getting the fd from the device.
This uses the new function introduced with libdrm 2.4.109. This has
already been updated in CI and is already required for mesa common
bits so requiring it for libdrm_amdgpu is no big deal.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13974>
This fixes building on macOS:
Disable ZINK_USE_DMABUF on macOS, it is unsupported.
Import vk_mvk_moltenvk.h for MVK_VERSION in zink_resource.c.
Add additional build arguments (see meson.build) to build properly.
To build on macOS, you will probably need to run:
brew install bison llvm cmake libxext xquartz ninja xorgproto meson
And you also need to setup meson with something like:
-Dmoltenvk-dir=/Users/<Username>/VulkanSDK/<VersionNumber>/MoltenVK
-Dc_std=c11
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14255>
Before meson 0.48 the cpu_family() would return 'ppc64le' on little
endian power8. In newer versions it returns 'ppc64' and endianness
should be checked with endian()
We now require meson >= 0.53 so we can drop the compatability with
older versions.
The old behavior was added in e430a034b9
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14240>
The feature was added in 0.55 but there was a bug when tests
crashed (and no XML file was generated) that was only fixed in 0.59.2.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14204>
Reviewed-by: Emma Anholt <emma@anholt.net>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153>
This is only going to be supported in the Amber branch
Reviewed-by: Emma Anholt <emma@anholt.net>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153>
This will now only be available in the Amber branch
Reviewed-by: Emma Anholt <emma@anholt.net>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153>
This will now only be available on the Amber branch
Reviewed-by: Emma Anholt <emma@anholt.net>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153>
This is now only going to be available in the Amber branch
Reviewed-by: Emma Anholt <emma@anholt.net>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153>
If you want this you will almost certainly be happier with the gallium
version, giving you llvmpipe instead of swrast-classic.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153>
However they have to be called via _glapi_get_dispatch/context. This
would be safe to do on any platform, but the extra indirection is only
necessary on Windows since TLS vars can't be exported from a DLL.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13634>
This bumps the supported dma-buf version up to 4 and adds the initial
dma-buf feedback implementation. It follows the changes in the dma-buf
protocol extension [1] to include the dma-buf feedback interface, which
should be incorporated by most Wayland compositors in the future.
From version 4 onwards, the dma-buf modifier events are not sent by the
compositor anymore, so we use the default feedback to pick the set of
formats/modifiers supported by the compositor. Also, we try to avoid the
wl_drm device event and instead use the dma-buf feedback main device. We
only fallback to wl_drm when the compositor advertises a device that
does not have a render node associated.
In this initial dma-buf feedback implementation we still don't do
anything with the per-surface dma-buf feedback, but in the next commits
we add proper support.
It's important to mention that this also bumps the minimal supported
version of wayland-protocols to 1.24, in order to include [1].
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11248>
Add function loader_get_render_node() to help us to get a render node
from dev_t. If the device does not expose a render node, this new
function returns NULL.
As this function uses drmGetDeviceFromDevId(), we bump libdrm minimal
version to 2.4.109.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11248>
TLSDESC speeds up access to dynamic TLS. This is especially important
for non-glibc targets, but is also helpful for non-initial-exec TLS
variables.
The entry asm does not support TLSDESC, but it only accesses
initial-exec symbols, so it is not necessary to handle that separately.
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12722>
It is not portable to use initial-exec TLS in dlopened libraries. glibc
and FreeBSD allocate extra memory for extra initial-exec variables
specifically for libGL, but other libcs including musl do not.
Keep initial-exec disabled on FreeBSD since it is apparently broken for
some reason:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/966#note_39451281dbdb15d5
Enable TLS on OpenBSD and Haiku based on the u_thread.h comment that
emutls is better than pthread_getspecific, which seems plausible given
that emutls has strictly more information to work with.
Fixes#966.
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12722>
Note that the Android build system apparently lowercases stuff,
so add a lowercase "directx-headers" dependency which is searched first,
before falling back to the proper-cased "DirectX-Headers" dependency.
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13532>
This might be safe to relax to all Windows compilers, but I didn't
test Clang or MinGW, so scoping to MSVC for now. For MSVC, this is
safe to mismatch, because the vftables are emitted into all objects
with "pick largest," and the definition with RTTI is larger than the
one without. This is different than the Itanium ABI, which only emits
one copy of the typeinfo in the object which defines the key method.
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13064>
-static-libstdc++ doesn't exist on the Android NDK, casuing all
later has_argument calls to return false even though the compiler
supports that argument.
Fixes: 3aee462781 "meson: add windows compiler checks and libraries"
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13164>
We've already ensured a few lines above that there is at least
`surfaceless` in the list.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13278>
