Bump xa minor to signal that the underlying mesa version is suitable for dri3.
This is a bit ugly since it doesn't relate to a specific xa interface change.
Recently there has been a number of fixes in mesa that helps enabling dri3
without any significant regressions in automated testing and common desktop
usage latency. However, the xf86-video-vmware driver has no other way to tell
but inspecting the xa version.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The configure.ac logic added in commit
2ef7f23820 ("configure: check if
-latomic is needed for __atomic_*") makes the assumption that if a
64-bit atomic intrinsic test program fails to link without -latomic,
it is because we must use -latomic.
Unfortunately, this is not completely correct: libatomic only appeared
in gcc 4.8, and therefore gcc versions before that will not have
libatomic, and therefore don't provide atomic intrinsics for all
architectures. This issue was for example encountered on PowerPC with
a gcc 4.7 toolchain, where the build fails with:
powerpc-ctng_e500v2-linux-gnuspe/bin/ld: cannot find -latomic
This commit aims at fixing that, by not assuming -latomic is
available. The commit re-organizes the atomic intrinsics detection as
follows:
(1) Test if a program using 64-bit atomic intrinsics links properly,
without -latomic. If this is the case, we have atomic intrinsics,
and we're good to go.
(2) If (1) has failed, then test to link the same program, but this
time with -latomic in LDFLAGS. If this is the case, then we have
atomic intrinsics, provided we link with -latomic.
This has been tested in three situations:
- On x86-64, where atomic instrinsics are all built-in, with no need
for libatomic. In this case, config.log contains:
GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE='#'
GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE=''
LIBATOMIC_LIBS=''
This means: atomic intrinsics are available, and we don't need to
link with libatomic.
- On NIOS2, where atomic intrinsics are available, but some of them
(64-bit ones) require using libatomic. In this case, config.log
contains:
GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE='#'
GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE=''
LIBATOMIC_LIBS='-latomic'
This means: atomic intrinsics are available, and we need to link
with libatomic.
- On PowerPC with an old gcc 4.7 toolchain, where 32-bit atomic
instrinsics are available, but not 64-bit atomic instrinsics, and
there is no libatomic. In this case, config.log contains:
GCC_ATOMIC_BUILTINS_SUPPORTED_FALSE=''
GCC_ATOMIC_BUILTINS_SUPPORTED_TRUE='#'
With means that atomic intrinsics are not usable.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Perhaps with a new version of autoconf, I began seeing:
| checking the name lister (/usr/bin/nm -B) interface... ./configure: line 6973: External.*some_variable: command not found
| BSD nm
This is because AC_PROG_NM expands to
...
if $GREP 'External.*some_variable' conftest.out > /dev/null; then
lt_cv_nm_interface="MS dumpbin"
fi
...
I'm not sure if it's a bug in AC_PROG_NM that it doesn't call
AC_PROG_GREP, but it's easy enough for us to do it.
When compiling with LLVM 6.0 on x86 (32-bit) for Android, the test
fails to detect that -latomic is actually required, as the atomic
call is inlined.
In the code itself (src/util/disk_cache.c), we see this pattern:
p_atomic_add(cache->size, - (uint64_t)size);
where cache->size is an uint64_t *, and results in the following
link time error without -latomic:
src/util/disk_cache.c:628: error: undefined reference to '__atomic_fetch_add_8'
Fix the configure/meson test to replicate this pattern, which then
correctly realizes the need for -latomic.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Due using a new VP9 config we use, required VA API 0.39
Fixes: 413c5ca372 ("travis: update libva required version")
CC: 18.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Add needed infrastructure to use performance monitor
requests for queries.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Chris Healy <cphealy@gmail.com>
nir_intrinsics.c existed as a static file until commit 76dfed8ae2 began
generating it as part of the build process. autotools is incapable of
coping, and so a build-tree from before this commit would then fail with
it:
[4]: *** No rule to make target '../../../mesa/src/compiler/nir/nir_intrinsics.c', needed by 'nir/nir_intrinsics.lo'. Stop.
Add a few lines to configure.ac to update the broken build files.
Fixes: 76dfed8ae2 ("nir: mako all the intrinsics")
The currently we use the singular CHECK_HEADER combined with explicit
append to the DEFINES variable. That is a legacy misnomer, since it
requires us to add $DEFINES to every piece that we build.
Using the plural version of the helper sets the HAVE_ macro for us, plus
ensures it's passed to the compiler - if config.h is available in there
(not in the case of mesa) otherwise on the command line.
In hindsight, we should replace all the AC_CHECK_{FUNC,HEADER} instances
with the plural version (or even the _ONCE suffixed version) and drop
the DEFINES hacks.
Fixes: cbee1bfb34 ("meson/configure: detect endian.h instead of trying
to guess when it's available")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105717
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Eric Engestrom <eric.engestrom@imgtec.com>
Tested-by: Clayton Craft <clayton.a.craft@intel.com>
We're trying to be -Wundef clean so that we can turn it on (and
eventually make it an error).
Note that the OMX code already used `#if ENABLE_ST_OMX_BELLAGIO` instead
of #ifdef; I could've changed these, but the point of -Wundef is to
catch typos, so we might as well make the change the right way.
Fixes: 83d4a5d5ae "st/omx/tizonia: Add H.264 decoder"
Fixes: b2f2236dc5 "st/omx/tizonia: Add H.264 encoder"
Fixes: c62cf1f165 "st/omx/tizonia/h264d: Add EGLImage support"
Cc: Gurkirpal Singh <gurkirpal204@gmail.com>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
The have-new-DRI3 codepaths would never actually properly trigger, since
there was a typo in configure.ac which broke the version check. This
went unnoticed but for an error in config.log if you looked closely
enough.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Lukas F. Hartmann <lukas@mntmn.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Fixes: 7aeef2d4ef ("dri3: allow building against older xcb (v3)")
Cc: Dave Airlie <airlied@redhat.com>
I'm not sure everyone wants to be updating their dri3 in a forced
march setting, this allows a nicer approach, esp when you want
to build on distro that aren't brand new.
I'm sure there are plenty of ways this patch could be cleaner,
and I've also not built it against an updated dri3.
For meson I've just left it alone, since if you are using meson
you probably don't mind xcb updates, and if you are using meson
you can fix this better than me.
v3: just don't put a version in for dri3/present without
modifiers, should allow building with 1.11 as well
(feel free to supply meson followups)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
When it is detected that a window could have been flipped
but has been copied because of suboptimal format/modifier.
The Vulkan client should then re-create the swapchain.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Adds support for multiple planes and buffer modifiers.
v4: Rename "has_dri3_v1_1" to "has_dri3_modifiers"
v12: Multi-planar/modifier support is now DRI3 v1.2; also update release
versions
Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
But the GPU is a pure render node and has no display engine, hence the
scanout needs to happen on the Tegra display hardware. The GPU and the
display engine each have a separate DRM device node exposed by the
kernel.
To make the setup appear as a single device, this driver instantiates
a Nouveau screen with each instance of a Tegra screen and forwards GPU
requests to the Nouveau screen. For purposes of scanout it will import
buffers created on the GPU into the display driver. Handles that
userspace requests are those of the display driver so that they can be
used to create framebuffers.
This has been tested with some GBM test programs, as well as kmscube and
weston. All of those run without modifications, but I'm sure there is a
lot that can be improved.
Some fixes contributed by Hector Martin <marcan@marcan.st>.
Changes in v2:
- duplicate file descriptor in winsys to avoid potential issues
- require nouveau when building the tegra driver
- check for nouveau driver name on render node
- remove unneeded dependency on libdrm_tegra
- remove zombie references to libudev
- add missing headers to C_SOURCES variable
- drop unneeded tegra/ prefix for includes
- open device files with O_CLOEXEC
- update copyrights
Changes in v3:
- properly unwrap resources in ->resource_copy_region()
- support vertex buffers passed by user pointer
- allocate custom stream and const uploader
- silence error message on pre-Tegra124
- support X without explicit PRIME
Changes in v4:
- ship Meson build files in distribution tarball
- drop duplicate driver_tegra dependency
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Tested-by: Andre Heider <a.heider@gmail.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Fixes: 26a9321d0a "freedreno: add global_bindings state"
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Allow only bellagio or tizonia to be used at the same time.
Detect tizonia package config file
Generate libomx_mesa.so and install it to libtizcore.pc::pluginsdir
Only compile empty source (target.c) for now.
GSoC Project link: https://summerofcode.withgoogle.com/projects/#4737166321123328
Acked-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Julien Isorce <julien.isorce@gmail.com>
v2: Refactor out screen functions to st/omx
Allows to keep all the code under st/omx (st/omx/tizonia and
st/omx/bellagio).
Reverts targets/omx_bellagio to omx as additions to existing files
is enough to compile for both bellagio and tizonia.
* autotools changes:
--enable-omx -> --enable-omx-bellagio
* meson changes:
-Dgallium-omx=false -> -Dgallium-omx=disabled
-Dgallium-omx=true -> -Dgallium-omx=bellagio
Acked-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Julien Isorce <julien.isorce@gmail.com>
Inspired-by: a similar patch for libdrm by Heiko Becker
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Also only check for wayland-scanner if building for the Wayland
platform.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: bfa22266cd ("vulkan/wsi/wayland: Add support for zwp_dmabuf")
Cc: Emil Velikov <emil.velikov@collabora.co.uk>
Reported-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105211
In line with wayland-client and wayland-server, move the check for
wayland-protocols into the wayland platform branch.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: bfa22266cd ("vulkan/wsi/wayland: Add support for zwp_dmabuf")
Cc: Emil Velikov <emil.velikov@collabora.co.uk>
Reported-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105211
pthread-stubs is no longer required on OpenBSD and has been removed.
libpthread parts involved moved to libc.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Cc: 17.3 18.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Since radv and radeonsi removed support for LLVM 3.9 the distcheck
target got broken because SWR distribution needed 3.9.x.
After checking with George Kyriazis, SWR is OK with moving to LLVM 4.0
and above, which will solve this problem.
Fixes: 3bf1e036e8 ("amd: remove support for LLVM 3.9")
Cc: George Kyriazis <george.kyriazis@intel.com>
Cc: Tim Rowley <timothy.o.rowley@intel.com>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Dylan Baker <dylan@pnwbakers.com>
Cc: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: George Kyriazis <george.kyriazis@intel.com>
v2: Only add as dependencies for gallium-osmesa and gallium-xlib
CC: <mesa-stable@lists.freedesktop.org>
Signed-of-by: Chuck Atkins <chuck.atkins@kitware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The default was toggled a while back, but the text wasn't updated.
Fixes: bd526ec9e1 ("configure: Always default to
--enable-driglx-direct")
Cc: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part 1 of 2 (part 1 is autoconf changes, part 2 is C++ changes)
When only a single SWR architecture is being used, this allows that
architecture to be builtin rather than as a separate libswrARCH.so that
gets loaded via dlopen. Since there are now several different code
paths for each detected CPU architecture, the log output is also
adjusted to convey where the backend is getting loaded from.
This allows SWR to be used for static mesa builds which are still
important for large HPC environments where shared libraries can impose
unacceptable application startup times as hundreds of thousands of copies
of the libs are loaded from a shared parallel filesystem.
Based on an initial implementation by Tim Rowley.
v2: Fix comment placement pointed out by Bruce C.
Signed-off-by: Chuck Atkins <chuck.atkins@kitware.com>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
CC: Tim Rowley <timothy.o.rowley@intel.com>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
The next change wants to use some optional zlib functionality, however
not all platforms currently use zlib. Based on earlier Jordan Justen's
patches and their review feedback.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
For devices (and kernels) which support different priority ringbuffers,
expose context priority support.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Because patch is more common than tiny for talking about the 3rd element
of a version.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Emil Velikov <emli.velikov@collabora.com>
Currently the versions are set in the header, and then sed is used to
extract them, so that autotools can use them elsewhere.
This is odd. Autotools is perfectly capable of configuring the header
with the versions, and then they don't need to be extracted from the
the header. This is cleaner and more obvious.
Tested with make distcheck.
v2: - Split tiny -> patch change
- Drop temporary variables
- change XA_VERSION_* -> XA_*
v3: - Finish splitting the tiny -> patch change
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Emil Velikov <emli.velikov@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com> (v2)
Tested with Travis and Appveyor.
v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
v3: use check_functions in Scons (Eric)
Cc: Rob Herring <robh@kernel.org>
Cc: Alexander von Gluck IV <kallisti5@unixzen.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a3648784 ("threads: update for late C11 changes")
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk> (v2)
While modern pthread mutexes are very fast, they still incur a call to an
external DSO and overhead of the generality and features of pthread mutexes.
Most mutexes in mesa only needs lock/unlock, and the idea here is that we can
inline the atomic operation and make the fast case just two intructions.
Mutexes are subtle and finicky to implement, so we carefully copy the
implementation from Ulrich Dreppers well-written and well-reviewed paper:
"Futexes Are Tricky"
http://www.akkadia.org/drepper/futex.pdf
We implement "mutex3", which gives us a mutex that has no syscalls on
uncontended lock or unlock. Further, the uncontended case boils down to a
cmpxchg and an untaken branch and the uncontended unlock is just a locked decr
and an untaken branch. We use __builtin_expect() to indicate that contention
is unlikely so that gcc will put the contention code out of the main code
flow.
A fast mutex only supports lock/unlock, can't be recursive or used with
condition variables. We keep the pthread mutex implementation around as
for the few places where we use condition variables or recursive locking.
For platforms or compilers where futex and atomics aren't available,
simple_mtx_t falls back to the pthread mutex.
The pthread mutex lock/unlock overhead shows up on benchmarks for CPU bound
applications. Most CPU bound cases are helped and some of our internal
bind_buffer_object heavy benchmarks gain up to 10%.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
So far clover based its test for compiler support on the version of gcc,
while in reality support for c++11 is required. This patch replaces the
version check by the check unified for all modules that require c++11.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Add a check that tests whether the c++ compiler supports c++11, either
by default, by adding the compiler flag -std=c++11, or by adding a
compiler flag that the user has specified via the environment variable
CXX11_CXXFLAGS.
The test only does a very shallow check of c++11 support, i.e. it tests
whether the define __cplusplus >= 201103L to confirm language support
by the compiler, and it checks whether the header <tuple> is available
to test the availability of the c++11 standard library.
A make file conditional HAVE_STD_CXX11 is provided that is used in this
patch to enable the test in st/mesa if C++11 support is available.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102665
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Currently we were overwriting the existing warning flags, instead of
adding new [as applicable].
Fixes c5d2e2d43f ("configure: Test for -Wno-initializer-overrides")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Currently we were overwriting the existing warning flags, instead of
adding new [as applicable].
v2: Add missing space before -Werror (Eric)
Fixes e4b2b69e82 ("configure: Add and use AX_CHECK_COMPILE_FLAG")
Cc: Matt Turner <mattst88@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Targets such as omx and va can work w/o anything X related. Mandate the
xcb* dependencies only when the X11 platform is selected.
Reported-by: Lukas Rusak <lorusak@gmail.com>
Fixes: 63e11ac2b5 ("configure: error out if building VA w/o supported
platform")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Tested-by: Lukas Rusak <lorusak@gmail.com> (v1)
Currently we error out when building GLVND w/o GLX.
That was the original premice before we had EGL. As the commit says,
that error should be reworked to honour both - do so.
v2: Drop noop *);; (Eric)
Reported-by: Lukas Rusak <lorusak@gmail.com>
Fixes: ce562f9e3f ("EGL: Implement the libglvnd interface for EGL (v3)")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Tested-by: Lukas Rusak <lorusak@gmail.com> (v1)
Nearly all the distributions* that build Mesa OpenCL, enable the ICD.
Since building a non-ICD driver has the chance of conflicting with
existing OpenCL binary (libOpenCL.so).
Furthermore, some applications expect the library to provide
annotated/versioned symbols.
https://lists.freedesktop.org/archives/mesa-dev/2017-September/171093.html
*Fedora, Suse, Arch, Debian, Ubuntu, FreeBSD use the ICD
Gentoo manages the conflicting files via eselect.
Cc: Matt Turner <mattst88@gmail.com>
Cc: Jan Vesely <jan.vesely@rutgers.edu>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-By: Aaron Watry <awatry@gmail.com>
Fixes reverted patch f03b7c9 by doing VMID reservation per
process and not per context.
Also updates required amdgpu libdrm version since the change
involved interface updates in amdgpu libdrm.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
I'm working on radeonsi support in the Chrome OS Android container
(ARC++). Mesa in ARC++ uses autotools instead of Android.mk, but all
the necessary EGL bits are there, so the existing check is too strict.
Signed-off-by: Benjamin Gordon <bmgordon@chromium.org>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
These are currently auto-generated, but meson needs the same files, so
lets commit them to reduce duplication.
v3: - Rename .build to build-support
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Coverage and LTO seems to be hard requirements for Clang, while
coroutines is needed as of LLVM/Clang 4.0.
Mark the last one as "optional" so we handle every case.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tobias Droste <tdroste@gmx.de>
We want to add "optional" components, which have been added with later
LLVM versions.
One such in-tree example is inteljitevents. Others are to follow
shortly.
v2: Use the correct function, add blank line between functions (Tobias)
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tobias Droste <tdroste@gmx.de>
Earlier versions need different quirks, but as of LLVM 3.9 llvm-config
provides --link-shared/link-static toggles.
The output of which seems to be reliable - looking at LLVM 3.9, 4.0 and
5.0.
Note that there are earlier code will be used for pre LLVM 3.9 and is
unchanged.
This effectively fixes LLVM static linking, while providing a clearer
and more robust solution for future versions.
Mildly interesting side notes:
- build-mode (introduced with 3.8) was buggy with 3.8
It shows "static" when build with -DLLVM_LINK_LLVM_DYLIB=ON, yet it was
consistent with --libs. The latter shows the static libraries.
- libnames and libfiles are broken with LVM 3.9
The library prefix and extension is printed twice liblibLLVM-3.9.so.so
v2: Invoke llvm-config twice, instead of using sed, to combine the two
lines into one (Tobias)
Cc: mesa-stable@lists.freedesktop.org
Cc: Dieter Nützel <Dieter@nuetzel-hh.de>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tobias Droste <tdroste@gmx.de>
As of LLVM 3.9 one could use consistent ways to handle the component.
Factor out the current handling, as it will be used for older versions.
Cc: mesa-stable@lists.freedesktop.org
Cc: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tobias Droste <tdroste@gmx.de>
Prior to the refactor/cleanup by Tobias one could add an invalid
component to LLVM_COMPONENTS.
Since that's no longer the case we can drop the current check.
Cc: Tobias Droste <tdroste@gmx.de>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tobias Droste <tdroste@gmx.de>
The only driver that utilises Clover already depends on LLVM 3.9.
Close to every supported distribution has said version.
Additionally libclc also requires LLVM 3.9.
With this in mind, we can safely bump the requirement.
There is a handful of dead code that we could remove, which will be
resolved with later commits.
Note: this drops the LLVM 3.6 build from the Travis build. LLVM 3.9 (and
later) are already covered in there.
https://lists.freedesktop.org/archives/mesa-dev/2017-September/170028.html
v2: Add reference to discussion thread (Eric), adjust libclc LLVM req.
(Jan).
Cc: Aaron Watry <awatry@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Acked-by: Vedran Miletić <vedran@miletic.net>
Acked-by: Jan Vesely <jan.vesely@rutgers.edu>
Acked-by: Francisco Jerez <currojerez@riseup.net>
V3D 3.3 is a continuation of the 3D implementation in VC4 (v2.1 and v2.6).
V3D 3.3 introduces an MMU (no more CMA allocations) and support for
GLES3.1. This driver is not currently conformant, though that will be a
target as soon as possible.
V3D 3.x parts use a new texture tiling layout common across many Broadcom
graphics parts including and the HVS scanout engine. It also massively
changes the QPU instructions, introducing a common physical register file
(no more A/B split) and half-float instructions, while removing the 4x8
unorm instructions in favor of half-float for talking to fixed function
interfaces. Because so much has changed, vc5 is implemented in a separate
gallium driver, using only the XML code-generation support from vc4.
v2: Fix tile layout for 64bpp textures. Fix texture swizzling for 32-bit
returns. Fix up a bit of MRT setup. Sync the simulator to kernel
behavior a bit more. Improve uniform debugging code. Rebase on
QIR->VIR rename. Move texture state mostly to the CSOs. Improve
cache flushing on the simulator. Fix program deletion
use-after-frees.
Acked-by: Dave Airlie <airlied@gmail.com> (uabi plan)
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (uabi plan)
My intent is to develop the vc5 driver in-tree for some time to build the
CL generation and shader compiler code, and keep out-of-tree patches for
talking to an actual kernel driver until the kernel driver can be
stabilized on the hardware.
v2: Define a HAVE_BROADCOM_DRIVERS, like HAVE_INTEL or HAVE_AMD.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
More tests could probably be added, but this should cover
concatenation, resizing, clearing, formatted printing,
and checking the length, so it should be quite complete.
Signed-off-by: Thomas Helland <thomashelland90@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle at amd.com>
Tested-by: Dieter Nützel <Dieter at nuetzel-hh.de>
V2: Address review feedback from Timothy, plus fixes
- Use a large enough char array
- Actually test the formatted appending
- Test that clear function resets string length
V3: Port to gtest
V4: Fix test makefile
Fix copyright header
Fix missing extern C
Use more appropriate name for C-file
Add tests for append_char
This marks the end of code sharing between r600 and radeonsi.
It's getting difficult to work on radeonsi without breaking r600.
A lot of functions had to be renamed to prevent linker conflicts.
There are also minor cleanups.
Acked-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
On some platforms, gcc generates library calls when __atomic_* functions
are used, but does not link the required library (libatomic) automatically
(supposedly to allow the app to use some other atomics implementation?).
Detect this at configure time and add the library when needed. Tested
on armel (library was added) and on x86_64 (was not, as expected).
Some documentation on this is provided in GCC wiki:
https://gcc.gnu.org/wiki/Atomic/GCCMM
Fixes: 8915f0c0 "util: use GCC atomic intrinsics with explicit memory model"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102573
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
At the moment wayland-clients, such as the Vulkan drivers were
over-linking against libwayland-server.so.
That went unnoticed, since both client and server code uses the
wl*interface symbols, which are present in both libwayland-client.so and
libwayland-server.so.
I've looked at correcting that, although that's orthogonal to this fix.
Note: wayland-egl does _not_ depend on wayland-client, although it does
need wayland-egl.h. There's no distinct package that provides it (I have
a WIP on the topic) so current solution will do for now.
v2: Rebase with the "...inline wayland_drm_buffer_get" patch removed.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Due to GCC feature described in previous commit, the expected
deprecation warnings may be missing.
Set the WL_HIDE_DEPRECATED macro which will omit the deprecated
functionality, resulting in more distinct build issues.
That is safe since the symbols guarded within the macro is static.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Glibc 2.26 has dropped xlocale.h, but the functions needed (strtod_l()
and strdof_l()) can be found in stdlib.h.
Improve the detection method to allow newer builds to still make use of
the locale-setting.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102454
Cc: Laurent Carlier <lordheavym@gmail.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Laurent Carlier <lordheavym@gmail.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Clang has "-Wno-initializer-overrides", while gcc has
"-Wno-override-init". Quiets a lot of warnings with clang.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
This makes it a lot clearer what's happening (at least I think so), and
will make future additions much simpler.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
https://bugs.llvm.org/show_bug.cgi?id=6823 still affects current LLVM.
llvm-config --libs only reports the single shared library if LLVM was
built with -DLLVM_LINK_LLVM_DYLIB=ON. llvm-config --shared-mode reports
"shared" in that case, "static" otherwise (even if LLVM was built with
-DLLVM_BUILD_LLVM_DYLIB=ON).
v2: Keep the LLVM < 4.0 test. (llvm-config --shared-mode is actually
available since LLVM 3.8, but that would make the test too
complicated :)
Fixes: 3d8da1f678 ("configure: Trust LLVM >= 4.0 llvm-config --libs
for shared libraries")
Bugzilla: https://bugs.freedesktop.org/102247
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
I've been trying to get away without these conditionals in vc4's NEON
code, but it meant compiling extra unused code on x86, and build failing
on ARMv6.
v2: Use the _arm/_arm64 flags to simplify detection (suggested by Rob),
but hide the _arm version under ARCH_ARM_HAVE_NEON to keep from trying
to build this stuff for armv5te.
Tested-by: Rob Herring <robh@kernel.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
No need to manually look for the library files anymore with current
LLVM. This sidesteps the manual method failing when LLVM was built with
-DLLVM_APPEND_VC_REV=ON.
(This might already work with older versions of LLVM)
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
spirv_info.c existed as a static file until commit 2dd4e2ece3 began
generating it as part of the build process. autotools is incapable of
coping, and so a build-tree from before this commit would then fail with
it:
[4]: *** No rule to make target '../../../mesa/src/compiler/spirv/spirv_info.c', needed by 'spirv/spirv_info.lo'. Stop.
Add a few lines to configure.ac to update the broken build files.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Use the .pc file, as provided by version prior 2.1.0 onward and dropping
the manual header/library check.
Version 2.1.0 was released back in Mar 2012 and all major distributions
use it.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (IRC)
Earlier commits moved the xmlconfig library to a wider userbase.
Thus having the check within --enable-dri is insufficient.
Upon closer look, nine needed it from it's early days - 948e6c5228
("nine: Add drirc options (v2)")
Fixes: 601093f95d ("xmlconfig: move into src/util")
Cc: Axel Davy <axel.davy@ens.fr>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (IRC)
Note that the Cray flags (-target-cpu=) need to come first since the
cray programming environment uses wappers around other compilers. By
checking the wrapper flags first, you can be sure to match the wrapper
flag instead of the underlying compiler (gcc, intel, pgi, etc.) flags.
Signed-off-by: Chuck Atkins <chuck.atkins@kitware.com>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
At dist/distcheck time we need to ensure that all the files and their
respective dependencies are handled.
At the moment we'll bail out as the linux-dmabuf rules are guarded in a
conditional. Move them outside of it and drop the sources from
BUILT_SOURCES.
Thus the files will be generated only as needed, which will happen only
after the wayland-protocols dependency is enforced in configure.ac.
v2: add dependency tracking for the header
Cc: Andres Gomez <agomez@igalia.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Andres Gomez <agomez@igalia.com>
This bumps the libdrm requirement for amdgpu to the 2.4.82.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Not built by default. Currently only builds with icc.
v2:
* document knl,skx possibilities for swr_archs
* merge with changed loader lib selection code
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Allow configuration of the SWR architecture depend libraries
we build for with --with-swr-archs. Maintains current behavior
by defaulting to avx,avx2.
Scons changes made to make it still build and work, but
without the changes for configuring which architectures.
v2:
* add missing comma for swr_archs default
* check that at least one architecture is enabled
* modify loader logic to make it clearer how to add archs
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The following changes need the modifier definitions for the Vivante tiled
formats, which are shipped with libdrm 2.4.82.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
When available, use the zwp_linux_dambuf_v1 interface to create buffers,
which allows multiple planes and buffer modifiers to be used.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
khrplatform.h is only used by EGL and GLES; let's only install it when
one of those is enabled.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Needing to get our uapi header from libdrm has only complicated things.
Follow intel's lead and drop our requirement for it.
Generated from the same commit mentioned in the README.
v2: Update Android.mk as well, move vc4_drm.h reference for distcheck.
Reviewed-by: Daniel Stone <daniels@collabora.com>
I really liked this idea, as it should help with management of packet
parsing tools like the CL dump. The python script is forked off of theirs
because our packets are byte-based instead of dwords, and the changes to
do so while avoiding performance regressions due to unaligned accesses
were quite invasive.
v2: Fix Android.mk paths, drop shebang for python script, fix overlap
detection.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Rob Herring <robh@kernel.org>
Implement assembly language API acceleration for PPC64LE,
analogous to long-standing implementations for X86 and X86-64.
See also similar implementation in libglvnd.
Tested with Piglit.
Signed-off-by: Ben Crocker <bcrocker@redhat.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Bill Schmidt <wschmidt@linux.vnet.ibm.com>
Thomas Hellstrom
Thomas Petazzoni
Matt Turner
Nicolas Boichat
Juan A. Suarez Romero
Marek Olšák
Christian Gmeiner
Emil Velikov
Eric Engestrom
Mathias Fröhlich
Daniel Stone
Dave Airlie
Emil Velikov
Louis-Francis Ratté-Boulianne
Thierry Reding
Gurkirpal Singh
Jonathan Gray
Andres Gomez
Jon Turney
Chuck Atkins
Grazvydas Ignotas
Rob Clark
Bas Nieuwenhuizen
Jason Ekstrand
Marc Dietrich
Vinson Lee
Dylan Baker
Nicolai Hähnle
Timothy Arceri
Gert Wollny
Andrey Grodzovsky
Benjamin Gordon
Eric Anholt
Thomas Helland
Michel Dänzer
Tim Rowley
Lucas Stach
Ben Crocker