Hi, I was looking a little bit around into performance of shaders. Obviously, the less operations the GPU has to execute, the better. Now I was checking the assembler code from FX Composer. I don't know much about optimization, so I tested a simple line:

// 1.
float3 value = tex2D( tex, texcoord );
       value = 2 * value -1;
// Compiled, 3 operations:
def c0, -1,-1,-1,-1
tex t0
add r0, t0, t0
add r0, r0, c0


// 2.
float3 value = tex2D( tex, texcoord );
       value = 0.5 * value -1;
// Compiled, 2 operations:
def c0, 0.5,0.5,0.5,0.5
def c1, -1,-1,-1,-1
tex t0
mad r0, t0, c0, c1

The second formula takes only 2 operations. But I would say formula 1 is more simple. MAD is a combination of 2 instructions, so I suppose its slower than ADD for example. Is there an overview to see how many cycles each instruction takes? I looked into the FX Composer Perf tool, but it says "cyles:1.00" for both formula's. Talking about optimizations. I compared 2 other lines:

float3 normal = 2 * tex2D( normalMap, texcoord ) -1;
float3 normal = 2 * ( tex2D( normalMap, texcoord ) -0.5 );

I would say the first line is faster, since I'm working with integer numbers. But the second line took 2 instructions instead 3: tex t0 add r0, t1_bias, t1_bias t0_bias? Doesn't that need to be calculated first somehow before? Greetings, Rick

Thanks!

But what still wonders me is the difference between the 2 ADDS or 1 MAD. Composer said they both need 1 cycle. But from a listing I saw, 1 ADD is also 1 cycle. So the 2 ADDS should be slower I think. But that's a little bit strange as well, since the compiler would choose the wrong optimization in that case.

I'm trying to write my Cg shaders a little bit proper. I noticed sometimes a shader can be faster (less operations/cycles) simply by putting a certain line somewhere else. I guess this has to do with the registers that are available. Could someone give a couple good tips when writing code in a high level language such as Cg?

Greetings,
Rick

Keep in mind that the assembly you see isn't necessarily the same that gets executed on the GPU. The driver will still change some instructions and reorder things a bit to pack instructions into the available slots for each cycle. There are also a bunch of other things going on behind the scenes, such as perspective correction operations when you access an interpolant.

The GF6 and GF7 both have two arithmetic units and a texture unit that execute instructions in a cascaded manner each cycle in the order ALU1 -> TEX -> ALU2. On a GF6, the first arithmetic unit can perform MOV, MUL, RCP, and DIV only. On a GF7, it can also perform ADD, MAD, and RSQ. (RSQ is broken on GF6 and is emulated in two cycles with LG2/EX2.) The second arithmetic unit can perform everything except RCP, DIV, and RSQ on both chips. A half-precision NRM.xyz instruction executes on a dedicated unit in parallel to the texture unit. Result operations such as scaling by 2, 4, 8, 1/2, 1/4, or 1/8, saturate, and signed saturate are free. The negation, absolute value, and some clamping operations on input values are free, as is the x*2-1 operation on a texture result.

This is just a very simple overview of the fragment shader functionality. The details are far more complex and involve things like register read and write ports and inter-unit bandwidth, but I'm not allowed to talk about those.

Quote:Original post by C0D1F1ED

Quote:Original post by Eric Lengyel
On a GF6, the first arithmetic unit can perform MOV, MUL, RCP, and DIV only. On a GF7, it can also perform ADD, MAD, and RSQ. (RSQ is broken on GF6 and is emulated in two cycles with LG2/EX2.) The second arithmetic unit can perform everything except RCP, DIV, and RSQ on both chips.

Just out of interest, where did you get this information? I know about the two execution units and roughly which instructions they can handle, but not details like RSQ being broken on Series 6 (is it truely broken or did they decide to save transistors by handling it as x1/2)?

A while ago, I did an obscene amount of reverse engineering of the NV4x driver. I can see and disassemble the hardware command buffer, and more pertinently to this thread, the actual machine instructions for vertex programs and fragment programs. The instruction word layouts are virtually the same on GF6 and GF7, but the opcode for RSQ is never used on GF6 -- the driver always generates LG2/EX2 instead, so I'm assuming that RSQ is broken. I was able to learn enough through reverse engineering that I wrote a low-level RSX driver for the PS3 which is now in use by Sony first-party game studios. Later, I was commissioned to do a study that involved the internal workings of the RSX fragment program hardware, so I had access to internal Nvidia documentation. I'm not allowed to talk about what I saw in those documents until 2016, but I can tell you things I learned through reverse engineering.

Quote:Original post by Eric Lengyel
I was able to learn enough through reverse engineering that I wrote a low-level RSX driver for the PS3...

I *BOW* To you, master Lengyel.

Seriously, my jaw literally dropped when I read this post.

Quote:Original post by spek
Talking about optimizations. I compared 2 other lines:

float3 normal = 2 * tex2D( normalMap, texcoord ) -1;float3 normal = 2 * ( tex2D( normalMap, texcoord ) -0.5 );

I would say the first line is faster, since I'm working with integer numbers.

Just to pick up on that: While integer math may be faster than float math on the CPU, it's not generally the case on the GPU. Remember that GPUs are designed to handle lots of floating-point data and that integer registers are a relatively recent addition.

Quote:But the second line took 2 instructions instead 3:
tex t0
add r0, t1_bias, t1_bias

t0_bias? Doesn't that need to be calculated first somehow before?

_bias is a modifier, as C0D1F1ED said, which is just hardwired to subtract 0.5 from its argument. It comes for free.