----- 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. 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
