----- 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. > so would we add another opcode that does exactly > the same thing and say that the first one can be emulated with float > comparisons? > I'm not sure if that helps. I guess we could change the first > one and make that one compare floats, then introduce another one that does > what IF currently is doing, but that seems weird as well. > Why not just say > that if your hardware can't do bitwise comparisons, just keep emulating them > with floats? That seems easier and it preserves the current behavior for > everyone. That's the point. Hardware can't do bitwise comparisons, and we need to emulate with floats, and for that we need a IF with float argument. And we need a IF with bitwise arguments for the rest. I really don't like the semantic of an opcode to depend on the hard capabilities. Jose _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
