The normalize may be faster in practice, but the intermediate code isn't very good indicator of speed, because it doesn't doesn't map directly to modern GPU machine code. A 3-component dot product is implemented as 3 scalar multiply-adds on current GPU's- so that's 3 instructions. The 3-component multiply will also compile to 3 instructions. Only very old GPU's still use native vector instructions.
Yes, it will only hint at what is happening. Notice, that even with machine codes you would still need to know how many cycles each instruction uses.
There is no way that I know of to view the actual native assembly code for any modern GPU's.
And abs is definitely very fast- I've heard that on some GPU's it's effectively free, as it can be combined into other instructions. But sign() being so slow is quite a shocker. It should be implemented as (f>=0) ? 1 : -1, which shouldn't be more than 2 instructions: a compare, and a conditional move instruction. I don't know why they did it in such a complicated way.
The native assembly for ATI cards can be viewed using their "GPU ShaderAnalyzer" (you can choose between all their architectures and see the machine code). For instance. sign(x) on ATI compiles to:
0 y: SETGT ____, 0.0f, KC0[0].x
z: SETGT ____, KC0[0].x, 0.0f
1 x: ADD R0.x, PV0.z, -PV0.y
while (f>=0) ? 1 : -1 compiles into
0 y: SETGT_DX10 ____, KC0[0].x, 0.0f
1 x: CNDE_INT R0.x, PV0.y, -1082130432, 1065353216
which is exactly as expected (the reason for difference is that sign(x) is required to have sign(0)=0).
I have also heard that abs (and saturate) should be free instructions, but I think that may depend on architecture. On ATI archs abs translated into a "MAX_DX10 ____, KC0[0].y, -KC0[0].y" instruction.
October 17, 2010, 08:36:39 PM
Dilber MC Theme by HarzeM