[Mesa-dev] TGSI declarations missing type info

[Christoph Bumiller]

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