Firstable, I’d like to greet u all guys, I’ve just recently discovered this forum and the intresting discussions taking place here, so I thought I might join in! )
Anyway, after reading many nVidia papers about their new CineFX architecture (NV30), I was pleasantly suprised to see that NV30 will allow for condition codes in PS. One of their papers contains the statement that while there isn’t any type of branching in PS, NV30 looks to support condition codes in the pixel shader pipelines that executes all branches, with the final value chosen at the end. This sort of format preserves the incredible predictability of dedicated 3D hardware, while adding significant flexibility.
I can definetly see why nVidia chose not to implement branching, but could u guys enlighten me in regards to what is/isn’t possible with condition codes and in what particular situations would it be better to use branching?
Also, do u think it was wise on nVidia’s side to implement condition codes instead of real flow control?
branching means to choose a way. that means jumps, normally. and that means without them you always have to execute the same (no if(not_needed) { dont_do_it() } optimizations) and you can not have loops… loops would be very handy for me… so i have to wait another generation
I dont think NV30 fragment program supports any branching, the condition codes seem to be only be for the kill instruction, and aditionally you can use the condition to mask register writes.
Killing the fragment stops the fragment processing dead in it’s tracks, and moves onto the next fragment. Which is useful for gaining back performance. Masking register writes is kindof a hacky way to do;
if( )
{ col = blah;
}
else
{ col = foo;
}
There doesn’t seem to be any forms of branching mentioned in the spec.
Real flow control in the fragment processor will turn up eventually, but its a year or two away at best.
Nutty
P.S. I’ve only skimmed thruogh the spec, so I may be wrong on some stuff
Originally posted by Nutty:
[b]I dont think NV30 fragment program supports any branching, the condition codes seem to be only be for the kill instruction, and aditionally you can use the condition to mask register writes.
Killing the fragment stops the fragment processing dead in it’s tracks, and moves onto the next fragment. Which is useful for gaining back performance. Masking register writes is kindof a hacky way to do;
[quote]
if( )
{ col = blah;
}
else
{ col = foo;
}
There doesn’t seem to be any forms of branching mentioned in the spec.
Real flow control in the fragment processor will turn up eventually, but its a year or two away at best.
Nutty
P.S. I’ve only skimmed thruogh the spec, so I may be wrong on some stuff [/b][/QUOTE]
You’re right m8, NV30 fragment program doesn’t support any form of branching, but it does support condition codes, which according to nVidia can be used to do many things u could also do with branching.
Right, the most obvious use for condition codes is to emulate branching. (Real branching can be faster if it lets you skip a lot of instructions, and the branch is either almost always taken or almost always not taken.)
It can get annoying to write out all the code for using condition codes. Fortunately, the Cg compiler should be able to help you out here and compile your “if” statements with no trouble.
You can think of condition codes as being the rough equivalent to “CMOV” instructions in x86.
Originally posted by mcraighead:
[b]Right, the most obvious use for condition codes is to emulate branching. (Real branching can be faster if it lets you skip a lot of instructions, and the branch is either almost always taken or almost always not taken.)
It can get annoying to write out all the code for using condition codes. Fortunately, the Cg compiler should be able to help you out here and compile your “if” statements with no trouble.
You can think of condition codes as being the rough equivalent to “CMOV” instructions in x86.
CMOV was introduced in the pentium. Then you also have the i386 instruction SET which can set a register to 0 or 1 depending on condition codes, not really the same but can be used as a replacement for branches too.
“Condition codes” is something more general and less powerful – it’s just bits telling you how some specific operations went.
What we DO with the condition codes is the interesting part. NV30 (and DX9, it seems) doesn’t support branching (based on condition codes or no) but does support predication. So let’s call this mechanism “predication” to be clear about what we’re talking about.
Predication, well, sort of. The important point is that you end up executing all the instructions on both sides of your “branch”. Predication sometimes implies that this is not the case. (Less important when instructions are not capable of generating “faults”.)
NV30 does support real (i.e. data-dependent) branching/looping/function calls in vertex programs. From the little I know of it, DX9 is quite a bit less general there. I also don’t know if DX9 supports CC’s.
Anyhow, CC’s are quite a nice improvement over the whole “SGE/MUL/MAD” mess.
)
I was actually very pleased when I first learned that there’s predication in the pixel pipe, too.