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

[Timothy Arceri]

On Thu, 2016-06-30 at 00:59 +0300, Grazvydas Ignotas wrote:
> 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.

I couldn't hit a crash using this method. However these traces do hit a
bug with the previous hack I did that could be the problem you are
seeing. I've pushed a fix to the same branch.

Now I'm trying to track down a problem where the walls and floor in the
room are missing in the trace from the bug on the first run. They are
there in the second run so it seems like another bug in the fallback
code.

> 
> Gražvydas
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev