[Mesa-dev] [RFC]: gallium: add new float comparison opcodes returning integer booleans

[Roland Scheidegger]

Am 09.08.2013 21:31, schrieb Roland Scheidegger:
> Am 09.08.2013 21:00, schrieb Christoph Bumiller:
>> On 09.08.2013 20:42, Roland Scheidegger wrote:
>>> This is a proposal for new comparison instructions, as the old ones
>>> don't really fit modern (graphic or opencl I guess for that matter)
>>> languages well.
>>> If you've got objections, think the naming is crazy or whatnot I'm open
>>> for suggestions :-). I would think this is not just a much better fit
>>> for d3d10/glsl but for hw as well.
>>
>> I think current hardware can do both, and as for the names, I'm fine
>> with the prefixed ones being the "modern" opcodes (prefix referring to
>> the source type in both cases) and the ones that are named exactly like
>> the legacy opcodes behaving like the legacy ones.
>>
>> Otoh newcomers might get confused and think the F prefix meaning that
>> they should return a float, we had a similar issue with legacy-KIL and
>> KILP-condition-is-predicate-if-any (and I just need to say again I'd
>> have preferred to keep the name KIL and rename KILP to DISCARD), but
>> seriously, the opcodes are documented so it should be no trouble to
>> figure out what they do (ok in practice that doesn't always work since
>> we sometimes like to read what we expect instead of what's actually
>> written).
> 
> Yes the naming gets a bit inconsistent. Now d3d10 just uses eq/ge/lt/ne,
> so basically the same as our old names but without the "s", and uses a
> prefix only for the integer comparison ones. But I really didn't feel
> like renaming the legacy ones (and reusing the old names for new
> behavior is just asking for trouble anyway).
> I guess something like SGEI etc. would also do but that doesn't look
> better to me neither. Now just d3d10 names would do too (so dropping the
> s) but that is inconsistent with the integer comparison opcodes too.
> Difficult problem :-).
> Though maybe another option would be to just rename all the integer
> comparisons too (dropping the "s") but I'm not sure there's really a
> good enough reason for changing the code everywhere just so the names
> are a bit more consistent.

I should probably mention there are of course other possibilities for
supporting this behavior without new opcodes:
- could extend instruction (or probably dst register) with return type
modifier field or something similar so the same opcode could be used for
either returning float or int bools.
- new shader property describing "shader model" (like legacy gl, glsl,
...). With that some instructions could change their behavior based on
it. (This would potentially also be useful to change things like NaN
handling, right now as you may have noticed we're tightening things up
to follow d3d10 rules in llvmpipe which are close to ieee754-2008 and
generally glsl ought to be happy with that, but I'm not sure yet if this
won't cause problems with legacy (both opengl and d3d9) shaders at least
for some cases as hw generally did support neither Inf's nor NaN's,
which otherwise would then need different instructions to fix. Of course
the gallium docs are very silent now about float behavior. This is just
a random idea though at this point.)
Adding new opcodes is just the straightforward solution (though we
actually don't have that much opcode space left).

Roland