<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 24, 2018 at 6:42 AM, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/24/2018 05:44 AM, Rob Clark wrote:<br>
> On Tue, Apr 24, 2018 at 4:24 AM, Samuel Iglesias Gonsálvez<br>
> <<a href="mailto:siglesias@igalia.com">siglesias@igalia.com</a>> wrote:<br>
>> Hello,<br>
>><br>
>> Recently, we have found problems between some SPIRV opcodes and NIR.<br>
>><br>
>> SPIR-V allows opcodes to mix different bit-sizes for their operands, such as for some bitfield operations and other ops like bitwise shifts.<br>
>><br>
>> In NIR, when the ALU opcode doesn't have specified bitsizes for their operands, it is expected to have both the same bitsize (see the assert in nir_build_alu() at nir_builder.h). I suppose this assumption comes from the time that NIR were only fed with GLSL IR but now with SPIR-V that assert is wrong.<br>
>><br>
>> Instead of adding new variants for the opcodes (such as nir_op_ishl16, or so) to workaround the issue, I think it is needed to fix this by removing this assumption from NIR and its validator. I send this email to ask for ideas and to find the best way to handle this.<br>
>><br>
> <br>
> Karol hit the same thing (with for example, shift instructions) with<br>
> the work for spv compute/kernel support.  I *think* the number of<br>
> special cases isn't too high, so probably vtn should just insert the<br>
> appropriate conversion instruction (ie. u2u32, etc) so that if the src<br>
> bitsize is incorrect it will be converted.<br>
<br>
</span>That's what I was going to suggest.  I guess it's possible that some HW<br>
might benefit from using the smaller bit-size, but the code generator<br>
should be able to see through the conversions to get the smaller data.<br>
</blockquote></div><br></div><div class="gmail_extra">Agreed.  I think most of these case should have no difference between the theoretical new opcode and original + conversion.  <br></div></div>