[Mesa-dev] NIR issue with SPIRV ops that have operands with different bit-size

[Samuel Iglesias Gonsálvez]

Thanks to all for the opinions.

I'm going to implement the conversion then.

Sam


On 24/04/18 15:45, Jason Ekstrand wrote:
> On Tue, Apr 24, 2018 at 6:42 AM, Ian Romanick <idr at freedesktop.org
> <mailto:idr at freedesktop.org>> wrote:
>
>     On 04/24/2018 05:44 AM, Rob Clark wrote:
>     > On Tue, Apr 24, 2018 at 4:24 AM, Samuel Iglesias Gonsálvez
>     > <siglesias at igalia.com <mailto:siglesias at igalia.com>> wrote:
>     >> Hello,
>     >>
>     >> Recently, we have found problems between some SPIRV opcodes and
>     NIR.
>     >>
>     >> SPIR-V allows opcodes to mix different bit-sizes for their
>     operands, such as for some bitfield operations and other ops like
>     bitwise shifts.
>     >>
>     >> 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.
>     >>
>     >> 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.
>     >>
>     >
>     > Karol hit the same thing (with for example, shift instructions) with
>     > the work for spv compute/kernel support.  I *think* the number of
>     > special cases isn't too high, so probably vtn should just insert the
>     > appropriate conversion instruction (ie. u2u32, etc) so that if
>     the src
>     > bitsize is incorrect it will be converted.
>
>     That's what I was going to suggest.  I guess it's possible that
>     some HW
>     might benefit from using the smaller bit-size, but the code generator
>     should be able to see through the conversions to get the smaller data.
>
>
> Agreed.  I think most of these case should have no difference between
> the theoretical new opcode and original + conversion. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180425/c9f8430a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180425/c9f8430a/attachment.sig>