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