If two shaders / permutations produce the same code, do we compile them twice?

[illwieckz]

If two shaders / permutations produce the same code, do we compile them twice?

[illwieckz]

If not, we may do an index of cached shader text checksum, not just an index of shader+permutation id so we can automatically deduplicate both compile time and storage.

[VReaperV]

The glsl caching code is a mess. It should be changed to be a straightforward "do all of the shader code processing, including adding macros, then check if we can load it based on that".

[VReaperV]

If two shaders / permutations produce the same code, do we compile them twice?

Is there an example of such permutations or shaders? If two permutations exist for the same shader that are created by setting different macros, yet produce the same results, then some macros should just be nuked.

[illwieckz]

I wonder if that happens with generic2D.

[VReaperV]

I wonder if that happens with generic2D.

You mean permutations of it?

[illwieckz]

Yes.

[illwieckz]

I mean I wonder if some permutations of generic2D and some permutations of generic may produce the same binary.

[VReaperV]

Yes.

There's only one: deph fade.

[VReaperV]

I mean I wonder if some permutations of generic2D and some permutations of generic may do the same.

Well, technically generic2D shader always has:

#if defined(GENERIC_2D)
	gl_FragDepth = 0;
#endif

[VReaperV]

(the other one doesn't)

[VReaperV]

The above is no longer true, now that the generic2D shader no longer uses that and is basically the same as generic one now.

[VReaperV]

If not, we may do an index of cached shader text checksum, not just an index of shader+permutation id so we can automatically deduplicate both compile time and storage.

This is probably the best option, especially considering some of the post-processing our shader sources go through, which is not cached properly I think.

[VReaperV]

Note that generic2D shader and the relevant macro no longer exist.

[VReaperV]

For only building the required shaders, see: #1294 (comment).