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

[Timothy Arceri]

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.