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

Timothy Arceri tarceri at itsqueeze.com
Thu Mar 2 20:47:44 UTC 2017



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.



More information about the mesa-dev mailing list