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

[Marek Olšák]

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.

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.