On Sun, Apr 14, 2013 at 5:24 PM, Roland Scheidegger <srol...@vmware.com>wrote:
> Am 14.04.2013 10:12, schrieb jfons...@vmware.com:> - TBD > > + Start an IF ... ELSE .. ENDIF block. Condition evaluates to true if > > + > > + src0.x != 0.0 > > + > > + where src0.x is interpreted as a floating point register. > Maybe should say something wrt evaluation of NaNs? I know we haven't > really established rules for comparisons etc. wrt NaNs but those > bools-as-float make me cry. I guess it is no different though than other > float opcodes, if we now really have a definition saying IF takes _any_ > float not just a bool-as-float which was loosely implied before. > > I don't know where the term "bool-as-float" came from, but I'd rather not use it unless it's properly defined somewhere, and TGSI doesn't have bools anyway, so why bother? The GLSL compiler or glsl-to-tgsi is responsible for converting bools to either floats or ints and TGSI shouldn't need to care. Both r300g and r600g use (src0.x != 0.0) for IF and (src0.x != 0) for UIF (r600-only), so there is always the "not-equal-to" operator, which is also well defined for NaNs. Also if you care about NaNs, we should start by defining how instructions should handle them, e.g. how relational operators handle NaNs, whether the multiplication operator follows the rule 0*anything = 0 (MUL, MAD, DP4, ...), etc. R600 have separate opcodes depending on what behavior you want, for example: - The MUL opcode follows the rule 0*anything = 0. (DX9) - The MUL_IEEE opcode follows the IEEE behavior. The other opcodes with both the DX9 and IEEE behavior are: MAD, DP4, EX2, LG2, RCP, RSQ. There are also separate MIN and MAX opcodes for DX9 and DX10. We should choose our opcodes carefully depending on whether we are implementing a DX9, DX10, OpenGL, or OpenCL state tracker. Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
