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

[Timothy Arceri]

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


>
> Marek
>
>
> On Thu, Mar 2, 2017 at 10:22 PM, Timothy Arceri <tarceri at itsqueeze.com> wrote:
>>
>>
>> On 03/03/17 07:47, Timothy Arceri wrote:
>>>
>>>
>>>
>>> On 03/03/17 03:39, Marek Olšák wrote:
>>>>
>>>> On Thu, Mar 2, 2017 at 5:36 PM, Mike Lothian <mike at fireburn.co.uk> wrote:
>>>>>
>>>>> I'm guessing when the code runs the 32bit and 64bit have different build
>>>>> times so invalidate the cache and create a new one
>>>>>
>>>>> On Thu, 2 Mar 2017 at 16:25 Marek Olšák <maraeo at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 2, 2017 at 3:03 PM, Mike Lothian <mike at fireburn.co.uk>
>>>>>> wrote:
>>>>>>>
>>>>>>> Is this because the 32bit and 64bit versions have slightly different
>>>>>>> time
>>>>>>> stamps used in the cache directory name? I was under the impression
>>>>>>> that
>>>>>>> the
>>>>>>> cache itself could be shared between 32bit & 64bit?
>>>>>>>
>>>>>>> I guess this only matters for the few games that offer both a 32bit
>>>>>>> and
>>>>>>> 64bit binary, producing duplicate entries in both caches potentially
>>>>>>
>>>>>>
>>>>>> In addition to that, I'd like to know why the CPU architecture is even
>>>>>> being considered. IMO, the CPU arch can be ignored for the shader
>>>>>> cache completely.
>>>
>>>
>>> Unfortunately it's not that simple, as per the code comment in the patch:
>>>
>>> "In theory we could share the cache between architectures but we have no
>>> way of knowing if they were created by a compatible Mesa version."
>>>
>>>>
>>>> Clearing the cache completely would be unwise. Why not just delete the
>>>> oldest entries like any other cache would do.
>>>>
>>>
>>> The problem with this is that for people using git and anyone running
>>> ppas we could end up with hundreds of directories, each with duplicate
>>> cache entries potentially taking up lots of space.
>>>
>>> If we were to go with the suggestion of deleting all but the two recent
>>> dirs the problem this patch trys to solve would remain. We have no way
>>> to know which dir was created for each arch and could end up with 2
>>> directories for the same arch ... although I guess we could argue that
>>> normal users even those on a ppas should always be updating in sync and
>>> users updating out of sync (git users/devs) just have to deal with
>>> caches getting blown away.
>>>
>>
>> Although with this we could be potentially wasting space as the user might
>> only ever run 32-bit or 64-bit apps and not both. This might be important on
>> vc4 were you have limited space on an sd card.