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