mesa: 0ab2dd361fd80c3840b1547cb7e05b4361eaf928 (master 17.1.0-devel) The build now fails on distributions without new enough zlib. There is not a way to build without requiring the shader cache. $ ./autogen.sh checking for ZLIB... no configure: error: Package requirements (zlib >= 1.2.8) were not met: commit 85a9b1b562b6a73b9494b3fad25172da3dc90fc2 Author: Timothy Arceri <tarceri@itsqueeze.com> Date: Wed Mar 1 16:04:23 2017 +1100 util/disk_cache: compress individual cache entries 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>
What distro ships prehistoric libz versions... libz 1.2.8 is 4 years old. Not sure this qualifies as a bug... (I think even MacOS now ships 1.2.8 albeit 10.11 indeed still shipped a prehistoric 1.2.5 which isn't really useful for compiling anything.) Or are just the headers missing?
Probably RHEL 6/CentOS 6. Looks like they ship a heavily patched 1.2.3. However I don't think this is Mesa's problem. We should recommend a version of zlib that see's regular testing against the shader cache. Corrupt output is not unheard of in zlib, so limiting the versions we need to deal with for regression testing is in our interest IMO.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.