22fa3d90a9
The more I think about it the more this seems like a bad idea. When we were deleting old cache dirs this wasn't so bad as it was unlikely we would ever hit the actual limit before things were cleaned up. Now that we only start cleaning up old cache items once the limit is reached the a percentage based max cache limit is more risky. For the inital release of shader cache I think its better to stick to a more conservative cache limit, at least until we have some way of cleaning up the cache more aggressively. Cc: "17.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> |
||
|---|---|---|
| .. | ||
| sha1 | ||
| tests/hash_table | ||
| .gitignore | ||
| Android.mk | ||
| bitscan.c | ||
| bitscan.h | ||
| bitset.h | ||
| build_id.c | ||
| build_id.h | ||
| crc32.c | ||
| crc32.h | ||
| debug.c | ||
| debug.h | ||
| disk_cache.c | ||
| disk_cache.h | ||
| format_r11g11b10f.h | ||
| format_rgb9e5.h | ||
| format_srgb.h | ||
| format_srgb.py | ||
| half_float.c | ||
| half_float.h | ||
| hash_table.c | ||
| hash_table.h | ||
| list.h | ||
| macros.h | ||
| Makefile.am | ||
| Makefile.sources | ||
| mesa-sha1.c | ||
| mesa-sha1.h | ||
| ralloc.c | ||
| ralloc.h | ||
| rand_xor.c | ||
| rand_xor.h | ||
| register_allocate.c | ||
| register_allocate.h | ||
| rgtc.c | ||
| rgtc.h | ||
| roundeven_test.c | ||
| rounding.h | ||
| SConscript | ||
| set.c | ||
| set.h | ||
| simple_list.h | ||
| slab.c | ||
| slab.h | ||
| string_to_uint_map.cpp | ||
| string_to_uint_map.h | ||
| strndup.h | ||
| strtod.c | ||
| strtod.h | ||
| texcompress_rgtc_tmp.h | ||
| u_atomic.c | ||
| u_atomic.h | ||
| u_atomic_test.c | ||
| u_endian.h | ||
| u_queue.c | ||
| u_queue.h | ||
| u_string.h | ||
| u_thread.h | ||
| u_vector.c | ||
| u_vector.h | ||
| vk_alloc.h | ||
| vk_util.h | ||