Ice Cold Specialization 🧊 #18887
Ice Cold Specialization 🧊 #18887
Conversation
tychedelia
added
A-Rendering
|
I think we may need to add a change tick cache for vertex layouts as these were trivially previously being covered by |
|
Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke! If it's expected, please add the M-Deliberate-Rendering-Change label. If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it. |
|
Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke! If it's expected, please add the M-Deliberate-Rendering-Change label. If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it. |
|
Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke! If it's expected, please add the M-Deliberate-Rendering-Change label. If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it. |
| } | ||
| } else { | ||
| mesh_key_cache.insert(*entity, mesh_key); | ||
| entity_specialization_ticks.insert(*entity, ticks.this_run()); |
There was a problem hiding this comment.
Isn’t the point to skip specialisation of the key didn’t change? One or the other of these branches looks wrong. Either this change tick was incremented suggesting that the key changed this run so specialisation is needed, which is wrong? Or the other branch incremented the change tick to indicate specialisation isn’t needed, which is wrong? Or I’m wrong :)
Objective
Currently, specialization uses a combination of
ChangedandAssetChangedto determine whether changes to a mesh or material requires the entity to be re-specialized. This is inefficient as most changes to a mesh or material cannot and should not actually affect the material's pipeline descriptor. Indeed, given the signature of thespecializefunction, the only things that can affect the descriptor are the mesh key, vertex layout, and material key.Solution
Use the mesh and material key to make all pipeline decisions. We still use change detection to select which entities may potentially require re-specialization, but then do an explicit check on their respective keys to determine whether specialization is actually necessary, greatly reducing unnecessary re-specializations when doing things like modifying a material's properties.
Testing
Ran some examples, this likely requires more substantive testing as these changes are highly likely to have broken something. Land early in
0.17to make sure issues are rooted out on main.