----- Original Message ----- > On 11/14/2011 09:48 PM, Christoph Bumiller wrote: > > On 11/14/2011 09:24 PM, Jose Fonseca wrote: > >> > >> > >> ----- Original Message ----- > >>> 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. > >> > >> I forgot about those. > >> > >> One thing that's common to all representations is that 0x00000000 > >> is false on all of them. So we could establish that as false. > >> > >> Another approach, make cleaner, would be to disallow CONST > >> booleans: i.e., the state tracker would use floats (0.0f/1.0f) or > >> ints, and then explicitely emit a comparison against the null > >> element to determine the boolean value: > >> > >> CONST[0] // boolean as float > >> CONST[1] // boolean as integer > >> CONST[2] // boolean as double > >> IMM[0] = {0, 1.0f} > >> > >> // TEMP[0] == (bool)CONST[0] > >> EQ TEMP[0], CONST[0], IMM[0].xxxx > >> > >> // TEMP[1] == (bool)CONST[1] > >> IEQ TEMP[1], CONST[1], IMM[0].xxxx > >> > >> // TEMP[2] == (bool)CONST[2] > >> DEQ TEMP[2], CONST[2], IMM[0].xxxx > >> > >> And the inverse for outputs. > >> > >> // OUT[0] = TEMP[0] ? 1.0f : 0.0f > >> SELECT OUT[0], TEMP[0], IMM[1], IMM[0] > >> > >> We need some way to encode integer/double immediates though. > >> > >>>> 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. > >> > >> This is confusing -- so the semantics of e.g., IF's argument, > >> depends on whether the pipe driver supports integers or not? > >> > > > > No, TGSI_OPCODE_IF only checks for zero/nonzero (thus NaN counts as > > I mean to say float -0. Anyway, the example was confusing, I just > meant > we do an u32 comparison for drivers that support integers. > > (This is where TGSI_OPCODE_IF may yield different results for > float-only > cards, but in practice it's never actually used with anything other > than > the result of a SET operation.)
My other reply was about this particular case. But I'm not convinced we can ignore this case at all. I'm fine with drivers cutting corners. By I can't accept an interface that's broken by design for all drivers. The argument from TGSI_OPCODE_IF may very well come from the application/state tracker as CONSTs. This means that state tracker would need to sanitize every const -0.0f => 0.0f, or emit code that did that before passing the TGSI_OPCODE_IF. Take a pick, but please keep this consistent. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev