cache_memory is reset to zero (with bad effects) if set to values >=2048
cache_memory option in preferences dialog is now set in MB and unlimited. In theory this should allow setting it to values higher than 2GB. In practice only prefs code uses bigger integer type (int64) while code that actually checks this setting still has hardcoded max value of 2GB and uses 32bit integer type (see src/common/mipmap_cache.c:640). When I try setting cache_memory to something like 2048 or 4096 it gets reset to zero and in result after restart all thumbnails are constantly being regenerated. We should either limit maximum value of this setting in preferences dialog (and revert to int32 type), or better yet fix the mipmap cache code to use 64bit integers and not to clamp this setting.
#1 Updated by Pascal Obry over 6 years ago
Ok, can you tell me if you are on a 64 or 32 bit machine?
Also, the code you're pointing is:
uint32_t max_mem = CLAMPS(dt_conf_get_int("cache_memory"), 100u<<20, 2u<<30);
So, it is an unsigned integer and it should be supporting up to 4gb I think. Maybe an issue in another place.
#4 Updated by Tobias Ellinghaus over 6 years ago
- System changed from other GNU/Linux to all
- Affected Version changed from git stable branch to git development version
- % Done changed from 0 to 20
- Status changed from New to Triaged
dt_conf_get_int() returns an int, so the unsigned doesn't help. We should probably use dt_conf_get_int64 as that is the type in the config, too.
#9 Updated by Igor Kuzmin over 6 years ago
Indeed it seem to be fixed now. The only complaint I can add is that user still can set mipmap cache size to very high values and he will get no notice that it's actually limited to 8GB. I think it would be a good idea to set the same limits for input fields in preferences as they are in the code using that variable.