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 <tarc...@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 <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.
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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
