Open lukaspj opened 10 years ago
Great idea.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb509610 additional note for fallbacks where folks just can't figure out an alternate. Will need to ask @LuisAntonRebollo if there is an equivalent problem and solution for OpenGL.
Okay, made some benchmarks with some better tools (the metrics(fps) is near useless in its current state) And here is my results for performance.
The benchmarking happened using a "camera bookmark" so it's recording the exact same place completely static. Numbers are the average FPS of 20 samples:
Blending Method | [branch] | default | no ifs |
---|---|---|---|
Lerp | 167 | 162 | 164 |
Heightmap | 155 | 154 | 157 |
So the initial "0.5 mspf" gain was a little over-estimated (a result of the metrics(fps) stuff... Too damn unstable FPS if you don't have an average value) but it's still noticeable for such a small change.
([branch] method is the one described in @Azaezel 's link.
For OpenGL3+ and DX10+ branching
are a recomended method for improve performance.
DX9 has some problems, not sure if are a API limitation or a shader model 2/3 hardware restriction.
I prefer no remove if
from code, we can add [branch]
to help compiler.
@lukaspj, thx for benchmark :)
This isn't exactly an issue, just a reminder for myself, and others, to look at all the shaders in T3D and eliminate if's where possible.
A small test where I tried eliminating all if's from my new terrain blending shader gave a 0.5 MSPF reduction. (155FPS -> 165FPS)
E.g:
Became:
This is because the GPU branches out on if-statements, and because of current GPU architecture, branching means it runs each branch for each pixel and discards the branches not used by the different pixels.
Meaning that if you have 1 if-statement, your code is run twice for each pixel.. Once for each possible outcome of the if-statement. It's best to try to avoid if's where possible to avoid this branching, even if it means doing some extra computations in the main body.