[Mesa-dev] [PATCH 1/2] util/disk_cache: support caches for multiple architectures

Timothy Arceri tarceri at itsqueeze.com
Fri Mar 3 23:33:10 UTC 2017



On 04/03/17 04:05, Alan Swanson wrote:
> On Fri, 2017-03-03 at 12:24 +1100, Timothy Arceri wrote:
>> On 03/03/17 11:53, Marek Olšák wrote:
>>>
>>> OK.
>>>
>>> I also wonder if 1GB isn't too conservative. Today’s games take up
>>> a
>>> lot of space. My installed games occupy 480 GB. I could certainly
>>> spare 10 GB for a shader cache if it improves gaming experience.
>>> For
>>> example, my ccache size is set to 27 GB, because 1 or 5 or 10 GB
>>> wasn't enough for my use case. I assume some gamers would have a
>>> similar attitude.
>>
>> Yeah I agree that 1GB is probably too small. This was set by Carl
>> before
>> we even knew how much data we needed to cache.
>>
>> I'm happy to set it at 4GB which would be a possible 8GB total.
>>
>> We may need to cap it at 4GB for some platforms anyway, or at least
>> figure out a work around for this:
>> https://bugs.freedesktop.org/show_bug.cgi?id=93089
>
> I wouldn't say that 1G was too small currently as, for example, the
> cache for shader heavy DeusEx:MD is ~50M compressed per your commit
> message. There is the mythical quote of 640K being enough but how many
> games and applications do you need cached at once?

Well it's not like we reserve the space, we would just not be imposing a 
small limit. The Dolphin emu is an example of an app that apparently 
creates a very large amount of shaders.

>
> A more relevant issue would then be the random eviction rather than
> using LRU eviction.

Happy to accept patches. The random evict code was written before my 
time on this.

>
> However perhaps we could dynamically scale by checking statvfs and
> quotactl to choose MAX[1G, MIN[10% user home filesystem, 10% user home
> quota]]?

Again patches welcome :)


>
> --
> Alan.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


More information about the mesa-dev mailing list