[Mesa-dev] TGSI declarations missing type info

Jose Fonseca jfonseca at vmware.com
Mon Nov 14 11:23:44 PST 2011

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


More information about the mesa-dev mailing list