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

[Ian Romanick]

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> 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.

> BR,
> -R
> 
>> What do you think?
>>
>> Sam
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev