RenderStateCache performance suffers in medium class projects.

[WangHoi]

Problem

With this project setup:

About 2400+ shader permutation, each shader(with all includes) about 10000+ lines.

The cache is populated, the subsequent load times are unsatisfactory.

Early inspection

When loading, RenderStateCache compute hash of full source, again and again.

Maybe we can get the internal hash string, and save it,
and next time provide the hash string,
then RenderStateCache check the Dearchiver first?

[TheMostDiligent]

Yes, I also thought that repeatedly computing hash may be a problem. As a solution I was thinking about caching the hashes of each file. This way the hash will be computed only once for each file so that the hash will not be repeatedly computed for the same include.

Another, even faster alternative might be to only hash the file name itself. However, in this cases the changes to the file will not trigger shader update, which makes this of limited use.

[WangHoi]

hmm, current computation is reliable, and your first solution sounds even better.

In a testing-release build, we hack a CacheKey, if specified, use it and skip the hash computation.
In real release build, we don't use RenderStateCache.

[TheMostDiligent]

How do you run in release build without the cache?

[WangHoi]

Use multiple Dearchiver,
One for Shadow, ColorGrading and other common PSO, developer maintain it.
One for Material Node Graph, auto generate from Material definition json files.

All use meaningful name as key, for example, a material PSO name:
"Type=Material PSO;Name=Material.002;SUBSHADER=Deferred.Opaque.GBuffer;LAYER_COUNT=2;"