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>
