On Tue, Apr 24, 2018 at 4:24 AM, Samuel Iglesias Gonsálvez <sigles...@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. BR, -R > What do you think? > > Sam > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
