Shader optimizations (skipping AND operands etc.)

[rosenand]

@midgunner66

your best bet for optimization is to write it out in a custom node (HLSL). ue4 only converts the node graph to an HLSL shader, it doesn’t actually compile it for your GPU. Because of this, ue4 may not write the HLSL code in the most optimal way. If you write it by hand, you’ll know what’s actually being done.

Hmm, I just started watching Epic’s stream about the Custom node. They show the documentation page where it warns that using the Custom node prevents constant folding. I checked and the warning is still there…

@midgunner66

In terms of readability, by using a math node, other people looking at it will see math. They will have to figure out what’s actually going on to realize that your actually just doing an if statement. By using an if statement, you explicitly say “this is an if statement”. Unless it improves performance by a lot, always write things out explicitly for better readability.

I’m at a smaller studio and so far, in the past 4 years, I was the only person doing our materials, and in case someone ever needs to take over I always comment everything and keep it tidy, so if there is a node group labeled e.g. “Range Mask 0/1”, and another labeled “Stencil Test 0/1”, both leading into a multiply, I think it’s readable enough. But I get your point I’ll probably switch back to IFs.

@midgunner66

It really doesn’t matter how this is setup, just that it logically works. You can even use 0.5 for the comparison: since the input will either be 0 or 1, it will never be equal to 0.5, so you only need to use the A>B and A<B inputs. I don’t think the performance will vary here at all (unless it’s a ue4 thing).

I remember vaguely that if A==B is connected, the material is converted into HLSL differently (probably because the equals condition has a threshold).

@midgunner66

Variation 2 is way worse. Not only is there more math, but there is a division (which is slower than multiply). They both logically do the same thing, but Variation 1 is straight to the point, whereas Variation 2 emulates it with math. If you were doing this in a situation where you only can use math operations (like on Desmos), you would use Variation 2.
And if you think about it, saturate uses if statements, too (n < 0 ? return 0; else n > 1 ? return 1), so you still technically have an if statement in there.

I thought Saturate would be faster than a full IF…Still I guess you make a valid point about the division.

@midgunner66

At the end of the day, nothing beats just testing and benchmarking it. Instead of spending a lot of time researching and speculating, you can just test it upfront (like what MostHost LA suggested). I find that just testing things upfront is faster than trying to find the solution online. The only caveat is things can change from GPU to GPU, so what works on your GPU may work differently on another GPU.

Yeah actually I’ve been testing stuff a lot lately, doing small builds and writing averaged performance measurements down for comparison, while learning how to optimize our project in terms of stuff like shader complexity, LODs, dynamic shadow casting settings, culling etc. As there’s no clear, universal guidelines fitting all projects, I arrived at the same conclusion as you: just test and find out. Even did it once with HLSL, actually: I was curious if the Clamp(0,1) node would compile into the same code as Saturate, so I checked in RenderDoc and it did. Once I changed (0,1) to something else, it produced more code.

Still, this topic can be a bit overwhelming, and my testing methodology could be flawed so I preferred to ask first to gain some foundations rather than to wander in the dark. So thank you for the explanation, I just started educating myself on fragment shaders etc. and it’s slowly starting to make sense.

Really appreciate all your answers!