[Mesa-dev] [PATCH] i965: Enable disk shader cache by default

[Jordan Justen]

On 2017-12-05 18:30:30, Mark Janes wrote:
> Timothy Arceri <tarceri at itsqueeze.com> writes:
> 
> > On 06/12/17 12:04, Mark Janes wrote:
> >> Jordan Justen <jordan.l.justen at intel.com> writes:
> >> 
> >>> On 2017-12-05 14:49:28, Mark Janes wrote:
> >>>> Jordan Justen <jordan.l.justen at intel.com> writes:
> >>>>> It could be interesting to define a MESA extension to control or query
> >>>>> the shader cache. Today, the shader cache is a nearly 'invisible'
> >>>>> feature. There are a few env-vars, but I wouldn't call a public
> >>>>> interface.
> >>>>>
> >>>>> The downside of defining an extension is that it might constrain
> >>>>> changes to the shader cache implementation. Or, if the interface is
> >>>>> too complex, then it may be tough for some drivers to implement.
> >>>>
> >>>> Why is an extension necessary?  By comparison, GCC has no interface to
> >>>> query the statistics for ccache.  A utility that can read the cache
> >>>> files and report hits/misses would at least inform us that the cache is
> >>>> functioning.  The utility would be useful in writing real unit tests for
> >>>> the feature.
> >>>
> >>> If we don't have an extension, then how would this work? i965 unit
> >>> tests during the build? If we don't actually test the feature against
> >>> real hardware, I think we'll miss a whole class of potential issues.
> >> 
> >> Unit tests are good, and I know we already have some of those.  We'll
> >> have better data on the classes of issues are once we find more of
> >> them.  So far, it's just a few hardware-independent piglit tests.
> >> 
> >>> If we don't have an extension, then how can an external (piglit) test
> >>> hope to interact or probe the cache?
> >> 
> >> Piglit queries a utility or lib to make assertions about the cache?  For
> >> that matter, this whole cache verification could be implemented within
> >> piglit as a profile that executes tests twice with appropriate
> >> verification.
> >
> > That would mean manual work to add tests to a profile. The manual part 
> > makes it unlikely to ever happen, also trying to manually update a list 
> > to test every variation of shader is doomed to fail. Alternatively 
> > adding only tests that have found a problem in the past makes it not 
> > very useful.
> 
> Are there not some cpu tests that can be easily dropped from the
> profile?

Looking in tests/cpu.py, I guess the asmparsertests are probably not
affected. (At least today, and that's unlikely to change.)

For the GLSLParserTest tests, they do interact with the shader cache,
so they should still be run.

Uh, not sure if I mentioned it previously, but the shader cache has no
need to run any vulkan tests.

-Jordan