On 04/24/2018 05:44 AM, Rob Clark wrote: > 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.
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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
