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 <i...@freedesktop.org > <mailto:i...@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 > > <sigles...@igalia.com <mailto: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. > > > Agreed. I think most of these case should have no difference between > the theoretical new opcode and original + conversion.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
