<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Thanks to all for the opinions.</p>
    <p>I'm going to implement the conversion then.</p>
    <p>Sam<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 24/04/18 15:45, Jason Ekstrand
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAOFGe94jdK+p1Ft-XPC91JeMwfi=2UwDJS_cuOPwBabe0yeK3A@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Tue, Apr 24, 2018 at 6:42 AM, Ian
            Romanick <span dir="ltr"><<a
                href="mailto:idr@freedesktop.org" target="_blank"
                moz-do-not-send="true">idr@freedesktop.org</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class="">On 04/24/2018 05:44 AM, Rob Clark wrote:<br>
                > On Tue, Apr 24, 2018 at 4:24 AM, Samuel Iglesias
                Gonsálvez<br>
                > <<a href="mailto:siglesias@igalia.com"
                  moz-do-not-send="true">siglesias@igalia.com</a>>
                wrote:<br>
                >> Hello,<br>
                >><br>
                >> Recently, we have found problems between some
                SPIRV opcodes and NIR.<br>
                >><br>
                >> SPIR-V allows opcodes to mix different
                bit-sizes for their operands, such as for some bitfield
                operations and other ops like bitwise shifts.<br>
                >><br>
                >> 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.<br>
                >><br>
                >> 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.<br>
                >><br>
                > <br>
                > Karol hit the same thing (with for example, shift
                instructions) with<br>
                > the work for spv compute/kernel support.  I *think*
                the number of<br>
                > special cases isn't too high, so probably vtn
                should just insert the<br>
                > appropriate conversion instruction (ie. u2u32, etc)
                so that if the src<br>
                > bitsize is incorrect it will be converted.<br>
                <br>
              </span>That's what I was going to suggest.  I guess it's
              possible that some HW<br>
              might benefit from using the smaller bit-size, but the
              code generator<br>
              should be able to see through the conversions to get the
              smaller data.<br>
            </blockquote>
          </div>
          <br>
        </div>
        <div class="gmail_extra">Agreed.  I think most of these case
          should have no difference between the theoretical new opcode
          and original + conversion.  <br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>