| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reduces the cache size for Deus Ex from ~160M to ~30M for
radeonsi (these numbers differ from Grigori's results below
probably due to different graphics quality settings).
I'm also seeing the following improvements in minimum fps in the
Shadow of Mordor benchmark on an i5-6400 [email protected], with a HDD:
no-cache: ~10fps
with-cache-no-compression: ~15fps
with-cache-and-compression: ~20fps
Note: The with cache results are from the second run after closing
and opening the game to avoid the in-memory cache.
Since we mainly care about decompression I went with
Z_BEST_COMPRESSION as suggested on irc by Steinar H. Gunderson
who has benchmarked decompression speeds.
Grigori Goronzy provided the following stats for Deus Ex: Mankind
Divided start-up times on a Athlon X4 860k with a SSD:
No Cache 215 sec
Cold Cache zlib BEST_COMPRESSION 285 sec
Warm Cache zlib BEST_COMPRESSION 33 sec
Cold Cache zlib BEST_SPEED 264 sec
Warm Cache zlib BEST_SPEED 33 sec
Cold Cache no compression 266 sec
Warm Cache no compression 34 sec
The total cache size for that game is 48 MiB with BEST_COMPRESSION,
56 MiB with BEST_SPEED and 170 MiB with no compression.
These numbers suggest that it may be ok to go with Z_BEST_SPEED
but we should gather some actual decompression times before doing
so. Other options might be to do the compression in a separate
thread, this might allow us to use a higher compression algorithim
such as LZMA.
Reviewed-by: Grigori Goronzy <[email protected]>
Acked-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=587210
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68504
Acked-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
radeon_llvm_check and friends were never called in the no-opencl case,
which ended up with an empty llvm module list. As --enable-opencl always
requires --enable-llvm, we can use the latter as the guard.
Signed-off-by: Marc Dietrich <[email protected]>
[Emil Velikov: commit message polish]
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise the configuration fails when building independant libs
like vdpau, vaapi or omx
Fixes: 1ac40173c2a ("configure.ac: simplify EGL requirements for
drivers dependent on EGL")
Signed-off-by: Leo Liu <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Cc: "17.0" <[email protected]>
|
|
|
|
| |
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a python generator to produce enum_to_str functions for
Vulkan from the vk.xml API description. It supports extensions as well
as core API features, and the generator works with both python2 and
python3.
Signed-off-by: Dylan Baker <[email protected]>
Acked-by: Matt Turner <[email protected]>
Acked-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
| |
Such that we can remove all the local fall-back definitions and use the
official UABI ones.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
| |
Provides the ability to read the .note.gnu.build-id section of ELF
binaries, which is inserted by the --build-id=... flag to ld.
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
| |
Released back in 2007 so it should not be an issue for anyone building
from git.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
dri2proto 2.8 was released 4+ years ago, so it must be of no surprise
for anyone building mesa from git.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Replace with AS_HELP_STRING and AC_MSG_ERROR respectively, as spotted by
autoupdate.
Note that the suggested AC_CANONICAL_SYSTEM > AC_CANONICAL_TARGET change
is not addressed here since that requires very extensive testing.
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drop all -m*, -W*, -O*, -g* and -f* flags, with the exception of
-fno-rtti, which must be used if it's part of the llvm-config --cxxflags
output. We don't want LLVM to dictate the flags we use, and it can even
cause build failures, e.g. if LLVM and Mesa are built with different
compilers.
While we're at it, eat any whitespace preceding dropped flags as well.
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we have extra (somewhat questionable) modularity, such that
one could build some parts with LLVM while others w/o.
That is extremely fragile, error prone and requires quite noticable
amount of code throughout.
Thus lets deprecate the gallium toggle in faviour of the generic one.
The former will throw a warning when set, and it will be overwritten by
the latter. This will allow gradual transition w/o breaking people's
scripts.
v2: Rebase, document in release notes.
Cc: Dave Airlie <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]> (v1)
|
|
|
|
|
|
|
|
|
|
|
| |
The extra function brings no added benefit as of earlier commit which
made llvm_require_version (as called by radeon_llvm_check) require LLVM
(--enable-gallium-llvm).
Fixes: 5f966a96af7 "configure.ac: Mandate --enable-gallium-llvm when
checking LLVM version"
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier refactoring commits changed from one, dare I say it, broken
behaviour to another. Namely:
Before, as you explicitly --enable-gallium-llvm your selection was
ignored when llvm-config was not present/detected.
Today, the "auto" heuristics enables gallium llvm regardless if you have
llvm/llvm-config available or not.
Rework the auto-detection to attribute for llvm's presence.
v2: Set enable_gallium_llvm=no when LLVM is not found.
Cc: "17.0" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
Reported-by: Samuel Pitoiset <[email protected]>
Tested-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
| |
Already implicitly handled throughout, but keep it clear and disable
gallium-llvm. This change should be a no-op.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier refactoring commits started setting the above regardless if LLVM
is used or not. Move them to the respective section to restore the
original functionality.
Since we require the preprocessor flags (includes in particular) for the
header version parsing keep those as-is. They are not used outside of
configure.ac thus should not cause any side-effects.
As-is adding the C/CXXFLAGS can lead to build issues on when
cross-compiling.
Cc: Ilia Mirkin <[email protected]>
Cc: Tomasz Figa <[email protected]>
Cc: "17.0" <[email protected]>
Reported-by: Ilia Mirkin <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
As stated in [1] by the LLVM devs, the new versioning scheme will not
deploy any minor version (i.e. it will always be zero). As such the
patch should not be needed.
This reverts commit 0e9a5be7e74fa2a9bd2a634ef60822bd6600ca1d.
[1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Although it works, it's not the correct thing to do.
v2: Rebase
v3: Rebase
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]> (v1)
|
|
|
|
|
|
|
|
| |
LLVM_BINDIR is completely unused while others such as LLVM_LIBDIR are
used only internally. In the latter case there's no need to AC_SUBST it.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure that HAVE_LLVM compiler define is only set if LLVM is
actually used.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99010
Cc: "17.0" <[email protected]>
Signed-off-by: Tobias Droste <[email protected]>
v2 [Emil] fold within the existing conditional
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set FOUND_LLVM only when LLVM is present (checking for exact version/etc
is deferred) and use enable-gallium-llvm to indicate the global LLVM
status.
Renaming the latter is not appropriate for stable patches, so we'll
address it with a later commit.
Loosely based on work by Tobias.
v2: Check FOUND_LLVM if enable_gallium_llvm is set.
Cc: Dave Airlie <[email protected]>
Cc: "17.0" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... to where it's applicable.
Since we effectively made --enable-gallium-llvm mean --enable-llvm with
earlier commits, we need to move the requirement to guard the compnents
added for the LLVM draw.
Otherwise we'll error (as below) when building RADV w/o gallium drivers.
configure: error: --enable-gallium-llvm is required when building radv
v2: Don't remove but move the dependency (Tobias).
Cc: Dave Airlie <[email protected]>
Cc: "17.0" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change we effectively require --enable-gallium-llvm when
building RADV. This should be perfectly safe since the gallium radeonsi
driver already explicitly requires it.
The "gallium" part in --enable-gallium-llvm is about to be removed soon
(not in stable), but until then make sure that things can build.
To reflect the requirement (as opposed to check previously) we rename
llvm_check_version_for to llvm_require_version
Cc: Dave Airlie <[email protected]>
Cc: "17.0" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drop the gallium prefix since we're about it use it throughout the
configure.
Note we do want to check for enable_gallium_llvm check since (as
explicitly requested) the toggle should mean --enable-llvm. Latter of
which to be resolved with later patches.
Cc: Dave Airlie <[email protected]>
Cc: "17.0" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is actually not needed because the version is checked later.
Around line 2380
if test "x$enable_gallium_llvm" == "xyes"; then
llvm_check_version_for $LLVM_REQUIRED_GALLIUM "gallium"
llvm_add_default_components "gallium"
fi
Cc: "17.0" <[email protected]>
Cc: Tobias Droste <[email protected]>
Signed-off-by: Tobias Droste <[email protected]>
Reviewed-by: Emil Velikov <[email protected]> (v1)
v2: [Emil Velikov: rebase/respin series order]
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
With next commits we'll require --enable-gallium-llvm (en route to a
greater good later on) for RADV. The latter is required to ensure that
as otherwise we'll fail to build.
Cc: Dave Airlie <[email protected]>
Cc: "17.0" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tobias Droste <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
| |
Not wired up (not referenced in any SUBDIR), leading to `make distcheck'
failure.
Fixes: d77fa310ed8 "ilo: EOL drop unmaintained gallium drv from buildsys"
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
There were two "libglvnd configuration" section in the squashed commit
that added libglvnd support, while only one in the original libglvnd
branch. A following commit moves one of them downwards. Now remove the
upper "older" one and move GL_LIB name decision downwards after the new
libglvnd configuration section.
Reviewed-by: Emil Velikov <[email protected]>
Signed-off-by: Boyan Ding <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: Rebase on top of ILO removal.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Andres Gomez <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
It's unlikely that any of the additions come as a suprise to anyone
i915, nouveau, radeon, r200. Regardless, state clearly what's
available.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Andres Gomez <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
This is no longer actively maintained and is just
accumulating bitrot.
Signed-off-by: Edward O'Callaghan <[email protected]>
Acked-by: Chia-I Wu <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intent of the libdrm_$driver version limits has always been to not
burden the "other" drivers with updating their libdrm unless really
necessary. Unfortunately the configure script erroneously only checked
the driver-specific bit and not the generic bit of libdrm as well. Fix
this.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
Although this might come from somewhere else require it explicitly.
Reviewed-by: Chad Versace <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
Fixes: b8acb6b17981 ("configure: Require libdrm >= 2.4.75")
Signed-off-by: Vinson Lee <[email protected]>
Acked-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Required to implement EGL_ANDROID_native_fence_sync on i965.
Specifically, i965 needs drm_intel_gem_bo_exec_fence(),
I915_PARAM_HAS_EXEC_FENCE, and libsync.h.
Reviewed-by: Rafael Antognolli <[email protected]>
Tested-by: Rafael Antognolli <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Analogous to what we do for the dri and gallium drivers.
Cc: 17.0 13.0 <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Analogous to previous commit(s), with a minor detail - here we set the
macros when building both C and C++ sources.
Resolving that is a more challenging task that we'll sort out another
day.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
b3119a3 introduced a strict LLVM requirement for r300 on all
architectures and thus configure fails on architectures where LLVM is
not available or buggy.
r300 doesn't strictly require LLVM, but for performance reasons we
highly recommend LLVM usage. So require it at least on x86 and x86_64
architectures as we have done before b3119a3.
Fixes: b3119a3 ("configure.ac: Check gallium LLVM version in gallium_require_llvm")
Cc: 17.0 <[email protected]>
Signed-off-by: Andreas Boll <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we'll get a lovely message as below:
"require_dri_shared_libs_and_glapi: command not found"
Cc: Steven Newbury <[email protected]>
Reported-by: Steven Newbury <[email protected]>
Fixes: da410e6afad "configure: explicitly require shared glapi for
enable-dri"
Signed-off-by: Emil Velikov <[email protected]>
Tested-by: Steven Newbury <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Earlier commit imported a SHA1 implementation and relaxed the SHA1 and
disk cache handling, broking the Windows builds.
Restrict things for now until we get to a proper fix.
Fixes: d1efa09d342 "util: import sha1 implementation from OpenBSD"
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment we support 5+ different implementations each with varying
amount of bugs - from thread safely problems [1], to outright broken
implementation(s) [2]
In order to accommodate these we have 150+ lines of configure script and
extra two configure toggles. Whist an actual implementation being
~200loc and our current compat wrapping ~250.
Let's not forget that different people use different code paths, thus
effectively makes it harder to test and debug since the default
implementation is automatically detected.
To minimise all these lovely experiences, import the "100% Public
Domain" OpenBSD sha1 implementation. Clearly document any changes needed
to get building correctly, since many/most of those can be upstreamed
making future syncs easier.
As an added bonus this will avoid all the 'fun' experiences trying to
integrate it with the Android and SCons builds.
v2: Manually expand __BEGIN_DECLS/__END_DECLS and document (Tapani).
Furthermore it seems that some games (or surrounding runtime) static
link against OpenSSL resulting in conflicts. For more information see
the discussion thread [3]
Bugzilla [1]: https://bugs.freedesktop.org/show_bug.cgi?id=94904
Bugzilla [2]: https://bugs.freedesktop.org/show_bug.cgi?id=97967
[3] https://lists.freedesktop.org/archives/mesa-dev/2017-January/140748.html
Cc: Mark Janes <[email protected]>
Cc: Vinson Lee <[email protected]>
Cc: Tapani Pälli <[email protected]>
Cc: Jonathan Gray <[email protected]>
Tested-by: Jonathan Gray <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Tapani Pälli <[email protected]> (v1)
Acked-by: Jason Ekstrand <[email protected]> (v1)
|
|
|
|
|
|
|
|
|
|
|
| |
Current code warns out in such cases and falls-back to either static or
shared. That can be easily missed amongst the volume produced by our
configure script.
Replace the warning with an error such that one gets direct feedback
when they're doing something wrong.
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
| |
We've been using and depending on it for at least a couple of years.
Make it obvious and error out, should one opt for it.
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
We have them for local purposes in configure, where we can use their
direct dependency.
With the only remaining instance in the makefile(s) being always true,
as it can be seen in the configure snippet.
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Both libraries implicitly require shared GLAPI which in itself mandates
shared libraries.
Stop pretending that one can use it and error out at configure stage.
Signed-off-by: Emil Velikov <[email protected]>
|