[Mesa-dev] [PATCH] tgsi: Add a conditional move inststruction

[Christoph Bumiller]

On 04.04.2013 16:53, Zack Rusin wrote:
>> On 04.04.2013 03:45, Zack Rusin wrote:
>>> It's part of SM4 (http://goo.gl/4IpeK). It's also fairly
>>> painful to emulate without branching. Most hardware
>>> supports it natively and even llvm has a 'select' opcode
>>> which can handle it without too much hassle.
>>>
>>> diff --git a/src/gallium/docs/source/tgsi.rst
>>> b/src/gallium/docs/source/tgsi.rst
>>> index 28308cb..6c5a02b 100644
>>> --- a/src/gallium/docs/source/tgsi.rst
>>> +++ b/src/gallium/docs/source/tgsi.rst
>>> @@ -72,6 +72,17 @@ used.
>>>  
>>>    dst.w = src.w
>>>  
>>> +.. opcode:: MOVC - Conditional move
>>> +
>>> +.. math::
>>> +
>>> +  dst.x = src0.x ? src1.x : src2.x
>>> +
>>> +  dst.y = src0.y ? src1.y : src2.y
>>> +
>>> +  dst.z = src0.z ? src1.z : src2.z
>>> +
>>> +  dst.w = src0.w ? src1.w : src2.w
>>>  
>> I think we already have that:
>>
>> .. opcode:: UCMP - Integer Conditional Move
>>
>> .. math::
>>
>>   dst.x = src0.x ? src1.x : src2.x
>>
>>   dst.y = src0.y ? src1.y : src2.y
>>
>>   dst.z = src0.z ? src1.z : src2.z
>>
>>   dst.w = src0.w ? src1.w : src2.w
>>
>>
>> No difference apart from the source ordering (the "integer" just implies
>> that any non-zero value counts as true, i.e. also inf, nan and -0).
> That's really broken. UCMP needs to be a an unsigned version of the CMP instruction which does
Did you mean signed version ?
Would you mind doing an s/UCMP/ICMP in TGSI and then chaning all the
UCMPs in other code to MOVC ?
You're right, it would make more sense like this, though you might want
to call it IMOVC so the condition register isn't interpreted as a float
... or is it supposed to be ?

> dst.chan = (src0.chan < 0) ? src1.chan : src2.chan
> not a whole new instruction. It's what everyone implements anyway. So if st_glsl_to_tgsi needs
> a conditional move we need to add the above patch and change it to use it.
>
>> And if you want more conditional ops, in theory we also have
>> predication, albeit support for that depends on the driver
>> (PIPE_SHADER_CAP_MAX_PREDS).
> No, that's a completely different thing. 
>
> z