On 03/03/17 03:39, Marek Olšák wrote:
On Thu, Mar 2, 2017 at 5:36 PM, Mike Lothian <m...@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 <mar...@gmail.com> wrote:
On Thu, Mar 2, 2017 at 3:03 PM, Mike Lothian <m...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
