On Tue, 2017-01-24 at 16:33 -0800, Eric Anholt wrote: > Timothy Arceri <t_arc...@yahoo.com.au> writes: > > > From: Timothy Arceri <timothy.arc...@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 :) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
