engine: add program cache #9297
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
z3moon
requested changes
Oct 7, 2025
show50726
reviewed
Oct 7, 2025
pixelflinger
reviewed
Oct 8, 2025
z3moon
requested changes
Oct 8, 2025
elizagamedev
force-pushed
the
exv/program-cache
branch
from
12ddadd to
2d1faeb
Compare
z3moon
requested changes
Oct 10, 2025
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.
elizagamedev
force-pushed
the
exv/program-cache
branch
from
2d1faeb to
27e4601
Compare
|
I actually think there's still some work that needs to be done here w/ matdbg, so please wait before reviewing again |
z3moon
reviewed
Oct 15, 2025
Comment on lines
-138
to
141
| SpecializationConstantsInfo const& getSpecializationConstants() const noexcept { | ||
| return mSpecializationConstants; | ||
| } | ||
|
|
||
| SpecializationConstantsInfo& getSpecializationConstants() noexcept { | ||
| SpecializationConstantsInfo getSpecializationConstants() const noexcept { | ||
| return mSpecializationConstants; | ||
| } |
There was a problem hiding this comment.
You can probably revert this as you explicitly copy the array below?
|
BTW, this change looks really good. And thanks for your patience. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.