----- Original Message ----- > > > ----- 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.
Oops. Some extra words in here. Strike "is that there are two" words out: a) 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 > > 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.) Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
