Hi,
I’m trying to clarify whether there is any GPU-side performance difference between MaterialInstanceDynamic (MID) and MaterialInstanceConstant (MIC).
My understanding is that both ultimately compile down to the same shader permutations and parameter bindings, and that the main differences are on the CPU side (runtime parameter changes, allocation cost, etc.).
However, I want to confirm whether using many MIDs instead of MICs can affect:
- GPU state changes or draw-call batching
- Parameter buffer updates or constant buffer allocations
- Caching of material uniform data
- Any other GPU-level cost I may be missing
In short: Does the GPU see any difference at all between an MID and an MIC, or is the impact exclusively CPU-side?
Thanks!
Hello,
Thank you for reaching out.
Yes, there is a way that using Material Instance Dynamic can affect the GPU time. Automatic draw-call batching cannot batch instances that use two different MID objects, even if the final parameters are the same.
The remaining difference is CPU-sided overhead to handle MID dynamic updates, when such updates occur.
For more information on how draw call merging is handled, please see “FMeshDrawShaderBindings::MatchesForDynamicInstancing(…)” from MeshPassProcessor.cpp. You can also refer to this documentation on the Mesh Drawing Pipeline:
https://dev.epicgames.com/documentation/en\-us/unreal\-engine/mesh\-drawing\-pipeline\-in\-unreal\-engine\#drawcallmerging
An alternative to MID is to use parameters bound to the Custom Primitive Data. This does allow draw call merging, but keeps the ability to set vector and scalar parameters on a per-object basis.
Please let us know if this helps.
Hello Stephen,
Thank you, the batching part is clear now.
What about the mobile renderer with GPUScene disabled: when there is no drawcall batching, is there any GPU overhead from using MID in this case?
Do MID and MIC use exactly the same shader code?
Hello,
If draw call merging is not a concern, then then UMaterialInstanceDynamic do not have any more overhead than UMaterialInstanceConstant.
Both UMaterialInstanceDynamic and UMaterialInstanceConstant will provide the same shader, given that their hierarchy shares the same shader permutation. IE, a UMaterialInstanceDynamic will return the same shader as it’s parent. However, a UMD and UMC that are siblings might not, if the UMC changes the permutation, such as by changing static switch parameters.
For more information, please see “FMaterialInstanceResource::GetMaterialNoFallback(…)” from MaterialInstance.cpp.
Please let us know if this helps.
Hello Stephen,
Thank you! Now everything is clear
Kind regards
Hello,
Thank you for the reply.
Can we now close your case? You can always re-open it if you find you have additional questions about the same topic.