summaryrefslogtreecommitdiffstats
path: root/src/util/Makefile.am
Commit message (Collapse)AuthorAgeFilesLines
* util: Add tests for the string bufferThomas Helland2017-09-261-1/+4
| | | | | | | | | | | | | | | | | | | | | | | 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
* configure: check if -latomic is needed for __atomic_*Grazvydas Ignotas2017-09-221-1/+2
| | | | | | | | | | | | | | | | | | 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>
* util: Link libmesautil into u_atomic_testMatt Turner2017-09-151-0/+1
| | | | | | | | | | Platforms without particular atomic operations require the implementations in u_atomic.c Cc: "17.2" <mesa-stable@lists.freedesktop.org> Fixes: a6a38a038bd ("util/u_atomic: provide 64bit atomics where they're missing") Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
* util: Fix build on old glibc.Eric Anholt2017-08-151-1/+3
| | | | | | | We need to link librt for u_thread.h's clock_gettime() call. Fixes: b822d9dd67b5 ("gallium/util: move u_queue.{c,h} to src/util") Reviewed-by: Matt Turner <mattst88@gmail.com>
* util: Makefile.am: add merge_driinfo.py in extra distJuan A. Suarez Romero2017-08-041-0/+1
| | | | Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
* xmlconfig: move into src/utilNicolai Hähnle2017-07-311-2/+18
| | | | | | | | v2: attempt to fix Android build (Emil) v3: add missing include path Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
* util/disk_cache: compress individual cache entriesTimothy Arceri2017-03-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 CPU@2.70GHz, 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 <greg@chown.ath.cx> Acked-by: Marek Olšák <marek.olsak@amd.com>
* util: automake: add sha1/README to the tarballEmil Velikov2017-02-241-1/+4
| | | | | Suggested-by: Andreas Boll <andreas.boll.dev@gmail.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
* util: import sha1 implementation from OpenBSD17.0-branchpointEmil Velikov2017-01-181-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mark.a.janes@intel.com> Cc: Vinson Lee <vlee@freedesktop.org> Cc: Tapani Pälli <tapani.palli@intel.com> Cc: Jonathan Gray <jsg@jsg.id.au> Tested-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Acked-by: Tapani Pälli <tapani.palli@intel.com> (v1) Acked-by: Jason Ekstrand <jason@jlekstrand.net> (v1)
* configure: Eliminate MSVC2008 compatibility.Jose Fonseca2016-02-111-1/+1
| | | | | | | | | | | | | | | We no longer need to build any part of Mesa with Windows SDK 7.0.7600 or MSVC 2008. MSVC 2013 will be the oldest we support. In practice this means people are now free to declare variables in the middle of blocks, on the whole Mesa tree. Care should still be taken with variable length arrays and void pointer arithmetic. Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Hella-acked-by: Ian Romanick <ian.d.romanick@intel.com>
* util: automake: rework the format_srgb.c ruleEmil Velikov2015-09-091-2/+4
| | | | | | | | | | | | | | A handful of changes/cleanups paving the way to bmake support: - Remove optional $(srcdir)/ prefix for files in the prereq list. - Drop the space after the AM_V_GEN variable. - Using $< in a non-suffix rule is a GNU make idiom. - Use $(@D) over $(dir $@). The latter is a POSIX standard. v2: Cosmetic tweaks in the commit summary. Cc: 11.0 <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
* util: always include sha1 into the buildIlia Mirkin2015-09-061-4/+0
| | | | | | | | | SHA1 is now used in all builds when HAVE_SHA1 is defined. Adjust src to do the same thing, rather than predicating on shader cache. Fixes: 04e201d0c02 ("mesa: change 'SHADER_SUBST' facility to work with env variables") Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Dave Airlie <airlied@gmail.com>
* util: Don't link to SHA1 library if shader-cache is disabled.Matt Turner2015-07-091-1/+1
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* util: Add a roundeven test.Matt Turner2015-03-181-1/+3
| | | | Reviewed-by: Carl Worth <cworth@cworth.org>
* Fix invalid extern "C" around header inclusion.Mark Janes2015-03-051-0/+3
| | | | | | | | | | | System headers may contain C++ declarations, which cannot be given C linkage. For this reason, include statements should never occur inside extern "C". This patch moves the C linkage statements to enclose only the declarations within a single header. Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
* configure: Leverage gcc warn options to enable safe use of C99 features ↵Jose Fonseca2015-03-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | where possible. The main objective of this change is to enable Linux developers to use more of C99 throughout Mesa, with confidence that the portions that need to be built with MSVC -- and only those portions --, stay portable. This is achieved by using the appropriate -Werror= options only on the places they need to be used. Unfortunately we still need MSVC 2008 on a few portions of the code (namely llvmpipe and its dependencies). I hope to eventually eliminate this so that we can use C99 everywhere, but there are technical/logistic challenges (specifically, newer Windows SDKs no longer bundle MSVC, instead require a full installation of Visual Studio, and that has hindered adoption of newer MSVC versions on our build processes.) Thankfully we have more directy control over our OpenGL driver, which is why we're now able to migrate to MSVC 2013 for most of the tree. Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* Revert "configure: Leverage gcc warn options to enable safe use of C99 ↵Kenneth Graunke2015-02-271-2/+1
| | | | | | | | | features where possible." This reverts commit 79daa510c7a871a33797308a2ccb4b83a067ffbe. I apparently hadn't done a clean build when testing this; it broke the build for Tom, Ben, and myself. We like the idea; let's try a v2.
* configure: Leverage gcc warn options to enable safe use of C99 features ↵Jose Fonseca2015-02-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | where possible. The main objective of this change is to enable Linux developers to use more of C99 throughout Mesa, with confidence that the portions that need to be built with MSVC -- and only those portions --, stay portable. This is achieved by using the appropriate -Werror= options only on the places they need to be used. Unfortunately we still need MSVC 2008 on a few portions of the code (namely llvmpipe and its dependencies). I hope to eventually eliminate this so that we can use C99 everywhere, but there are technical/logistic challenges (specifically, newer Windows SDKs no longer bundle MSVC, instead require a full installation of Visual Studio, and that has hindered adoption of newer MSVC versions on our build processes.) Thankfully we have more directy control over our OpenGL driver, which is why we're now able to migrate to MSVC 2013 for most of the tree. Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* mesa: Add gallium include dirs to more parts of the tree.Eric Anholt2015-02-201-0/+2
| | | | | | v2: Try to patch up the scons bits. Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
* configure: Add machinery for --enable-shader-cache (and --disable-shader-cache)Carl Worth2015-01-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't actually have the code for the shader cache just yet, but this configure machinery puts everything in place so that the shader cache can be optionally compiled in. Specifically, if the user passes no option (neither --disable-shader-cache, nor --enable-shader-cache), then this feature will be automatically detected based on the presence of a usable SHA-1 library. If no suitable library can be found, then the shader cache will be automatically disabled, (and reported in the final output from configure). The user can force the shader-cache feature to not be compiled, (even if a SHA-1 library is detected), by passing --disable-shader-cache. This will prevent the compiled Mesa libraries from depending on any library for SHA-1 implementation. Finally, the user can also force the shader cache on with --enable-shader-cache. This will cause configure to trigger a fatal error if no sutiable SHA-1 implementation can be found for the shader-cache feature. Bug fix by José Fonseca <jfonseca@vmware.com>: Fix to put conditional assignment in Makefile.am, not Makefile.sources to avoid breaking scons build. Note: As recommended by José, with this commit the scons build will not compile any of the SHA-1-using code. This is waiting for someone to write SConstruct detection of the available SHA-1 libraries, (and set the appropriate HAVE_SHA1_* variables). Reviewed-by: Matt Turner <mattst88@gmail.com>
* mesa: Add mesa SHA-1 functionsCarl Worth2015-01-161-0/+7
| | | | | | | | | | | | | | | | | The upcoming shader cache uses the SHA-1 algorithm for cryptographic naming. These new mesa_sha1 functions are implemented with any one of several differeny cryptographics libraries. This code was copied from the xserver repository, (where it has apparently been functioning well on a variety of operating systems), and comes licensed with a license identical to that of Mesa. Bug fixes by José Fonseca <jfonseca@vmware.com>: Fix to put conditional assignment in Makefile.am, not Makefile.sources to avoid breaking scons build. Fix include file for CryptoAPI section. Fix missing cast in openssl section. Reviewed-by: Matt Turner <mattst88@gmail.com>
* util: Wire up u_atomic_test.Matt Turner2014-12-121-0/+3
|
* mesa: Add scons files to distribution.Matt Turner2014-12-121-1/+1
|
* util: Add headers and python scripts for distribution.Matt Turner2014-12-121-0/+1
|
* mesa: Move register_allocate.c to util.Eric Anholt2014-09-231-0/+3
| | | | | | | | | | | | | The r300 gallium driver is using it outside of the Mesa tree, and I wanted to do so for vc4 as well. Rather than make the multiple-definitions problem even more complicated, just move it to more-shared code. v2: Don't forget to delete the symlink in r300 (review by Matt). Delete more r300-helper references (review by Emil) Don't prefix util/ header inclusion with "util/" (review by Emil) Reviewed-by: Matt Turner <mattst88@gmail.com> (v1) Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v1)
* util: remove ralloc_testEmil Velikov2014-08-081-25/+5
| | | | | | | | | The tests in an empty stub, which we're currently building twice. If anyone is interested in expanding it (adding actual tests) they can always bring it back. Suggested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* gallium: Move sRGB <-> RGB handling to libmesautilJason Ekstrand2014-08-041-1/+10
| | | | | Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* util: Gather some common macrosJason Ekstrand2014-08-041-2/+0
| | | | | | | | | | This gathers macros that have been included across components into util so that the include chain can be more vertical. In particular, this makes util stand on its own without any dependence whatsoever on the rest of mesa. Signed-off-by: "Jason Ekstrand" <jason.ekstrand@intel.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* util: Move the open-addressing linear-probing hash_table to src/util.Kenneth Graunke2014-08-041-0/+1
| | | | | | | | | | | | | | | | | This hash table is used in core Mesa, the GLSL compiler, and the i965 driver, which makes it a good candidate for the new src/util module. It's much faster than program/hash_table.[ch] (see commit 6991c2922f5 for data), and José's u_hash_table.c has a comment saying Gallium should probably consider switching to a linear probing hash table at some point. So this seems like the best candidate for a shared data structure. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> v2 (Jason Ekstrand): Pick up another hash_table use and patch up scons Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* util: Move ralloc to a new src/util directory.Kenneth Graunke2014-08-041-0/+53
For a long time, we've wanted a place to put utility code which isn't directly tied to Mesa or Gallium internals. This patch creates a new src/util directory for exactly that purpose, and builds the contents as libmesautil.la. ralloc seemed like a good first candidate. These days, it's directly used by mesa/main, i965, i915, and r300g, so keeping it in src/glsl didn't make much sense. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> v2 (Jason Ekstrand): More realloc uses and some scons fixes Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com>