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

[Timothy Arceri]

On Fri, 2016-07-01 at 14:12 +1000, Timothy Arceri wrote:
> 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?u
> > sp
> > =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.

Not sure if you are still interested in testing but I've just pushed
some updates to the shader-cache branch. These replace the missing
shader source hack with a proper solution, fix some UBO bugs and fix a
couple of other issues noticed alone the way.

More than happy for you to point out further issues :)

Tim

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