On 11/14/2011 08:23 PM, Jose Fonseca wrote: > > > ----- Original Message ----- >> The next open question I have is whether this warrants additions to >> the tgsi_opcode_info struct, mainly whether the return value is >> uint/int/float, >> and whether then src regs are uint/int/float, I'm not 100% that all >> opcodes always take all int/uint/float srcs, but my memory is a bit >> hazy on what the outliers might be. > > I agree that adding this sort of info to tgsi_opcode_info would be a code > typing saver for all drivers. > > However I never looked at the integer/double opcode set, but from quickly > skimming d3d10/11 headers, there are three buckets: > - arithmetic: (u)ints -> (u)int > - comparison: (u)ints -> mask (and I don't know what's the semantic of these > masks: 0/~0, 1.0f/0.0f, 0/1, or what) > - conversion: float <-> (u)int > > > And likewise to double, minus the unsigned vs signed split. > > So, probably we need tgsi_opcode_info to distuinguish the source type vs dest > type, but we likely don't need per-source types. > > > > A much more intricate question, is how to represent boolean mask in a mixed > type world. My guess is one of two: > > a) is that there are two we should not mandate the bit representation of a > boolean (drivers are free to implement booleans as 1.0f/0.0f, 0/~0, etc). The > only constrainsts is that the state tracker never tries to write a boolean > directly to an output. >
Booleans can be set by the user (CONST) and thus the state tracker has know what drivers want. > b) if by some miracle, all hardware implements boolean vectors in the same > way, then we could stick to that. (For sse/avx/llvm-2.9, the natural way to > represent a boolean vector is a bitmask (0/~0). llvm 3.0 finally added > support for bit vectors.) > > Currently, classic mesa uses 1/0, gallium uses 1.0f or ~0 depending on whether the driver supports integers. Also, the float SET opcodes return 1.0f/0.0f so there has to be conversion if the driver supports integers, and the integer SET opcodes are supposed to return ~0. In SM4, all comparison operations return ~0/0. (<= nv40 only support 1.0f, nv50 supports only ~0, nvc0 can do both; conversion is a single instruction (convert to s32 with negation)). > > Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev