Timothy Arceri <[email protected]> writes: > From: Timothy Arceri <[email protected]> > > 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?
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
