[Mesa-dev] [PATCH 08/37] glsl: add initial implementation of shader cache
Eric Anholt
eric at anholt.net
Wed Jan 25 00:33:08 UTC 2017
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. I'm really curious to see how this would work out for a gallium
driver.
Could you extend the file's doxygen comment to cover some of these
design decisions?
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170124/e7cf8522/attachment.sig>
More information about the mesa-dev
mailing list