An alternative would be to remove this optimization altogether, and
always use the node_bsdf_principled_clearcoat shader.
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- temp-fix-principled-coat
- Build Status
Buildable 791 Build 791: arc lint + arc unit
Event Timeline
Comment Actions
So you confirmed that this fixes the slowdown? If so seems fine to me.
Also I think you accidentally added the wrong reviewer.
Comment Actions
So you confirmed that this fixes the slowdown? If so seems fine to me
Which slowdown are you referring to?
The issue I tackled (T52441) is that to implement the optimization (i.e., use principled_simple instead of principled_clearcoat) in the C side, we would need to force shader recompilation every time the clearcoat value changed from 0.0 to anything else, and vice-versa.
Adding branching in glsl is far from ideal, but in Linux NVidia and AMD - testing with Clt+Alt+D 23 + Alt+A: "Material Shader Pass" - I got similar numbers for clearcoat 0.0, and 1.0, with and without the patch. @Clément Foucault (fclem) got some worse results in his system, but I suspect the issue is with the lack of a better shader profiling system.
Note: to try this without the patch you need to force shader recompilation after you change clearcoar from/to 0.0.
Comment Actions
For me this seems to be an acceptable workaround although branching might not be that performant.
Comment Actions
I was referring to the 2.22ms -> 2.84ms slowdown mentioned in the report. I was just wondering if that's entirely solved or if it's somewhere in between.
Branching by itself isn't necessarily slow, I mainly would expect additional uniforms or extra register pressure from a more complex shader to have an impact. But if you confirmed it's solved then that's fine of course.