[Mesa-dev] [PATCH 08/37] glsl: add initial implementation of shader cache

Timothy Arceri timothy.arceri at collabora.com
Wed Jan 25 01:22:14 UTC 2017


On Tue, 2017-01-24 at 16:33 -0800, Eric Anholt wrote:
> Timothy Arceri <t_arceri at yahoo.com.au> writes:
> 
> > From: Timothy Arceri <timothy.arceri at collabora.com>
> > 
> > This uses disk_cache.c to write out a serialization of various
> > state that's required in order to successfully load and use a
> > binary written out by a drivers backend, this state is referred to
> > as
> > "metadata" throughout the implementation.
> > 
> > This initial version is intended to work with vertex and fragment
> > shader stages only.
> 
> This is really interesting.  I was definitely expecting that the
> cache
> at this level would be a map from ([sha1s of shader source], mesa
> version, compiler options, other linker inputs) -> ([compiled GLSL IR
> shaders], linker metadata output).  The advantage you seem to be
> going
> for is to not have GLSL IR ever present in memory, which would be
> pretty
> cool.

That's the plan. It does mean we need some special handling for when we
must fallback to a recompile (i965 shader variants, corrupt cache
items, etc) but it's not so bad. It certainly simpler that caching the
IR. In the i965 patchset I add an environment var to enabled this
fallback path to be forced for debugging.

>   I'm really curious to see how this would work out for a gallium
> driver.

Yeah I really haven't looked at this very hard yet. I'll start looking
at it next week, but my assumption was we might need 3 levels of cache
for a gallium driver. glsl, gallium and backend caches.
 
> 
> Could you extend the file's doxygen comment to cover some of these
> design decisions?

Sure.

> 
> Also, I think in this series you've missed having the
> gl_shader_compiler_options options in the shader key, which I believe
> might affect the compiled metadata output.  Other than that, will
> gallium vs i965 have different GLSL IR passes being run at the
> CompileShader or LinkShader stages before we write to disk?  Will we
> need the driver's name to be in the key, maybe?

See my reply to patch 6 I think that should cover all of these issues. 

I'd really like it if that didn't hold this up from landing however as
I'd really like to start working on improvements rather than constantly
wasting time rebasing things :)


More information about the mesa-dev mailing list