2f1266f7dd
* 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
4.0 KiB
4.0 KiB