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

Kenneth Graunke kenneth at whitecape.org
Fri Dec 8 00:48:43 UTC 2017


On Thursday, December 7, 2017 9:57:48 AM PST Matt Turner wrote:
[snip]
> But the entire API boils down to a comparatively small set of
> non-orthogonal state. The configuration of those nobs seems to me like
> the place things are most likely to break.

I do like Matt's idea of adding Piglit tests specifically for NOS items.
Even if we don't add tests for every item in a key, adding tests that
hit two variants of an item in the key would ensure that we're using the
right key, and not pulling the wrong one from the cache.

Yes, it's a problem with the existing in-memory cache, but it would also
be nice to have additional coverage of that.

Another idea I had was to extend the ARB_program_interface_query tasks
to have a mode (command line argument) that causes them to compile the
shader twice.  For example:

1. Compile the shader
2. Check program interface query properties
3. Delete the shader
4. Compile the shader again - which should be a cache hit
5. Check program interface query properties again

Most of these properties come from the IR and associated metadata.
That would be a way to verify that we get that right.  I think it would
have caught the VUE map bug relating to unify_interfaces() not getting
called when restoring from the cache.

It also sounds relatively easy on paper.

If we validated NOS, and validated PIQ, then I'd feel pretty good about
the cache working with only a single run.  The run-the-whole-suite-twice
idea is nice, but most people aren't going to do that on every single
patch (maybe daily?).  I'd like to have better coverage within a single
run.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171207/d17f24dc/attachment.sig>


More information about the mesa-dev mailing list