On Jan 30, 2017 4:15 AM, "Lionel Landwerlin" <lionel.g.landwer...@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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
