[Mesa-dev] [PATCH 2/2] spirv: handle undefined components for OpVectorShuffle

[Jason Ekstrand]

On Jan 30, 2017 4:15 AM, "Lionel Landwerlin" <lionel.g.landwerlin at intel.com>
wrote:

On 27/01/17 09:57, Juan A. Suarez Romero wrote:

> On Fri, 2017-01-27 at 09:46 +0000, Lionel Landwerlin wrote:
>
>> But what the test does is calling OpSpecConstantOp[2], which is the
>>> operation we are patching here.
>>>
>>> And according to the spec, "all Operands must be the <id>s of other
>>> constant instructions", being constant instructions those starting with
>>> OpConstant or OpSpec. In this regard, OpUndef is not a constant.
>>>
>> I noticed this indeed. Given that test were specifically written to test
>> this, I thought OpVectorShuffle had priority on this rule.
>>
>> I think that when calling OpVectorShuffle directly, OpUndef can be
> used, but when using through OpSpecConstantsOp, the operands are
> restricted to constants.
>
>
> I just filed a bug against the spec to get clarification on this.
>>
>
> I was to send a fix to the test, to remove the OpUndef usage. But I
> think I'll wait until this is clarified. Thanks!
>
>
Just to keep you updated, I've only got one comment on the SPIRV
specification issue (issue 119 btw).
It seems that Undef should be allowed. Feel free to comment there if you
think otherwise.


I took a look at the spec today and it certainly could stand to be more
clear.  I think, given that OpUndef can show up at the to of a SPIR-V
shader with the constants and types that it makes sense to treat it as a
constant.  That said, read as written, OpUndef is not a constant and
therefore disallowed.  We'll see what happens on the bug but my guess is
that it will probably end up getting allowed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170130/b062d76a/attachment.html>