[Mesa-dev] V3 On disk shader cache for i965 (Now with real world results!)

[Grazvydas Ignotas]

On Wed, Jun 29, 2016 at 3:11 PM, Timothy Arceri
<timothy.arceri at collabora.com> wrote:
> On Wed, 2016-06-29 at 03:47 +0300, Grazvydas Ignotas wrote:
>> On Tue, Jun 28, 2016 at 10:53 AM, Timothy Arceri
>> <timothy.arceri at collabora.com> wrote:
>> > On Mon, 2016-06-27 at 00:46 +1000, Timothy Arceri wrote:
>> > > On Sun, 2016-06-26 at 16:15 +0300, Grazvydas Ignotas wrote:
>> > > > Tried this while playing with apitrace and am getting segfaults
>> > > > when
>> > > > running any trace with a cached (second) run. Not sure if it's
>> > > > "wrong"
>> > > > traces I've chosen or what, you can take one example from this
>> > > > bug:
>> > > > https://bugs.freedesktop.org/show_bug.cgi?id=96425
>> > >
>> > > Thanks for testing I'll take a look tomorrow.
>> >
>> > The problem is the shaders were being detached after linking so we
>> > had
>> > nothing to fallback to if we had a shade cache miss.
>> > I've hacked something up and pushed it to the shader-cache19 branch
>> > that allows the trace to run. Not sure how it relates to real game
>> > performance but the trace goes from 5FPS to 7FPS on the second run
>> > on
>> > my machine with which looks good :)
>>
>> Seems to work now and makes things a good deal faster. nice!
>>
>> However I have a case of one trace's cache seemingly affecting
>> another
>> trace, are you interested in that?
>
> Yes, very interested in any bugs :)
>
>>  One of them (the one that gets
>> broken) is from this bug:
>> https://bugs.freedesktop.org/show_bug.cgi?id=92229
>> Unfortunately the other "bad" one is my own and is over a gigabyte
>> (even compressed), I'll need to trim it I guess.
>
> If your happy to upload it somewhere I'm happy to download it.

Ok then, it's here:
https://drive.google.com/file/d/0Bz8fw_SGGDzsZVBMSWF6dlRCMFE/view?usp=sharing

Steps to reproduce:
rm -rf ~/.cache/mesa
MESA_GLSL_CACHE_ENABLE=1 glretrace -b Soma_slow_trim.x86_64.trace
MESA_GLSL_CACHE_ENABLE=1 glretrace -b Soma.bin.x86_64.trace # from bug 92229

The first one should hit an assert due to reasons unrelated to cache,
after that playing the second one crashes on free() due to some
corruption for me. If you remove the "bad" cache and just play the
second one, it works with empty and it's own full cache.

Gražvydas