[Mesa-dev] [PATCH] tgsi: document and fixup IF and BREAKC instrunctions

[Jose Fonseca]

----- Original Message -----
> > ----- Original Message -----
> > > ----- Original Message -----
> > > > Ah.. This indeed rings a bell. I don't recall the details but I'm
> > > > pretty
> > > > sure
> > > > I was against dual semantics. And the fact that this problem is again
> > > > showing its ugly head is the proof of it.
> > > > 
> > > > We really should have two IF opcodes. And the state tracker should
> > > > choose
> > > > which one it wants.
> > > 
> > > What would be the difference between those two opcodes though?
> > 
> > > The current IF
> > > does a bitwise comparison,
> > 
> > No, according to Marek, the current IF code has two possible behaviors:
> > - a float comparison for drivers which do not support native integers
> > (i915)
> > - a bit comparison for drivers which support native integers (others)
> > 
> > This would be the different for both opcodes. We could call the former FIF
> > or
> > just IF, and the later UIF.
> 
> Yes, I understand what you're arguing for, I don't understand how you want to
> get there with those two opcodes. Do you want to change the current tgsi
> exec behavior of IF and introduce a new UIF opcode or do you want to
> introduce a new FIF opcode that does the float comparisons? 

tgsi exec supports native integers, therefore it could just implement bitwise IF, and assert that float IF is never emited.

However, because some state trackers (not Mesa), don't fully respect this (and always emit float IF), it's probably better to have tgsi_exec and gallivm to support both float/bitwise variants for a transitory period.

all other drivers should only support one IF opcode:
- svga, i915, r300(?) should only support the float IF
- all others should only support the bitwise IF

I'd recommend reuse TGSI_OPCODE_IF for the float IF, and introduce TGSI_OPCODE_UIF for the bitwise IF.

> Also, which one
> does the current glsl compiler depend on?

Mesa state trackers emits only one IF, but it will pass uint args for drivers that support native integers, and 1.0/0.0 float args for drivers that don't. I think this matches the GLSL semantics too.

Jose