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 <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