Files
Eliza 2f1266f7dd engine: add program cache (#9297)
* engine: add program cache

This is another chunky change.

The core of this change is to cache programs in MaterialCache according to a
"specialization" (ProgramSpecialization) which is defined as the program cache
ID (the same key used for the OpenGL binary blob cache), the variant, and the
set of spec constants.

As part of this change, a lot of the implementation details of shader
compilation were refactored from Material to MaterialDefinition. The resulting
flow is a lot cleaner and easier to reason about, since shader compilation is
now a pure function of the MaterialDefinition + ProgramSpecialization.

Since the global cache program lookups might take a bit of time to compute
hashes, etc, I left the set of cached programs in Material as well, which kind
of acts like an L1 cache. The effect is that prepareProgram() and getProgram()
should be no slower than HEAD, even with the more complex caching requirements.

I'm planning on writing a document about this (and all changes up until this
point), but I'm being asked to work on higher priority things and I wanted to
have this PR out for review in the meantime so it doesn't bitrot.

* engine: fix unit tests

* engine: fix spec constants intern pool memory leak

* engine: address program cache comments

* engine: address more program cache comments

* engine: matdbg support for program cache

* engine: reinstate descriptorLayout calls

* engine: address bitrot

* engine: add feature flag to disable program cache

* engine: use material CRC32 for program cache

The "cache ID" of a material is supposed to uniquely identify a shader program
and all its variants. This is true to a certain extent, but does not account for
the code generation that happens at runtime. Two materials may have "identical"
shader programs, but due to each material's differing unique metadata, the final
compiled programs may end up very different. Unfortunately, this means we cannot
rely on the "cache ID" alone to determine a shader program's reusability.

Ideally, we should hash this "cache ID" with the exact set of changes to each
shader program so that we could reuse programs across materials. Instead, as a
stopgap solution, use the material's CRC32 instead.

* engine: fix double-free in program cache

* engine: address comments

* engine: assert_invariant empty material cache
2026-01-27 13:09:42 -08:00
..
2018-08-03 10:38:22 -07:00
2018-08-03 10:38:22 -07:00
2018-08-03 10:38:22 -07:00
2020-02-12 10:03:06 -08:00
2018-08-03 10:38:22 -07:00