<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 3, 2018 at 10:24 AM, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">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 07/03/2018 07:09 AM, Jason Ekstrand wrote:<br>
> Do we do this in fs?  I'm very confused as to how any deref instructions<br>
> can survive this late.  They can for fs but only for images (not<br>
> textures). I would expect them to be killed off by DCE long before we<br>
> get here.<br>
<br>
</span>I didn't debug this to great depth.  Once I found a couple shaders that<br>
hit this (apologies for sending the wrong shader to IRC), I ran with a<br>
breakpoint set at the fprintf.  Once that was triggered, I looked at the<br>
instruction type.  I saw that it was always nir_instr_type_deref, so I<br>
looked at fs_visitor::nir_emit_instr to see how it was handled there.  I<br>
then copied that code verbatim.<br>
<br>
I think texture accesses in the vertex shader was a red herring.<br>
Looking at the NIR coming out of one of the shaders, I see:<br>
<br>
<br>
        decl_var  INTERP_MODE_NONE vec4[4] t7<br>
        decl_reg vec4 32 r0[4]<br>
<br>
        ...<br>
<br>
        vec1 32 ssa_50 = deref_var &t7 (local vec4[4]) <br>
        vec1 32 ssa_51 = deref_array &(*ssa_50)[0] (local vec4) /* &t7[0] */<br>
        vec2 32 ssa_52 = fmul ssa_5, <a href="http://ssa_49.zw" rel="noreferrer" target="_blank">ssa_49.zw</a><br>
        vec2 32 ssa_53 = ffma ssa_47, <a href="http://ssa_49.zw" rel="noreferrer" target="_blank">ssa_49.zw</a>, ssa_52<br>
        vec4 32 ssa_54 = txl ssa_53 (coord), ssa_0 (lod), <br>
        r0[0] = imov ssa_54<br>
        vec1 32 ssa_55 = deref_array &(*ssa_50)[1] (local vec4) /* &t7[1] */<br>
        vec2 32 ssa_56 = fmul ssa_7, <a href="http://ssa_49.zw" rel="noreferrer" target="_blank">ssa_49.zw</a><br>
        vec2 32 ssa_57 = ffma ssa_47, <a href="http://ssa_49.zw" rel="noreferrer" target="_blank">ssa_49.zw</a>, ssa_56<br>
        vec4 32 ssa_58 = txl ssa_57 (coord), ssa_0 (lod), <br>
        r0[1] = imov ssa_58<br>
        vec1 32 ssa_59 = deref_array &(*ssa_50)[2] (local vec4) /* &t7[2] */<br>
        vec2 32 ssa_60 = fmul ssa_8, <a href="http://ssa_49.zw" rel="noreferrer" target="_blank">ssa_49.zw</a><br>
        vec2 32 ssa_61 = ffma ssa_47, <a href="http://ssa_49.zw" rel="noreferrer" target="_blank">ssa_49.zw</a>, ssa_60<br>
        vec4 32 ssa_62 = txl ssa_61 (coord), ssa_0 (lod), <br>
        r0[2] = imov ssa_62<br>
        vec1 32 ssa_63 = deref_array &(*ssa_50)[3] (local vec4) /* &t7[3] */<br>
        vec2 32 ssa_64 = fmul ssa_9, <a href="http://ssa_49.zw" rel="noreferrer" target="_blank">ssa_49.zw</a><br>
        vec2 32 ssa_65 = ffma ssa_47, <a href="http://ssa_49.zw" rel="noreferrer" target="_blank">ssa_49.zw</a>, ssa_64<br>
        vec4 32 ssa_66 = txl ssa_65 (coord), ssa_0 (lod), <br>
        r0[3] = imov ssa_66<br>
<br>
Maybe inadequate DCE is the problem?<br><div class="HOEnZb"><div class="h5"></div></div></blockquote><div><br></div><div>I think so.  Given that we're dealing with arrays, I supsect lower_locals_to_regs is leaving them lying around.  We don't see a problem in FS because lower_locals_to_regs does nothing there (all local variables are gone long before thanks to lowering indirects away).  Also, FS has to silently ignore derefs because we still use variables for image_load_store.  I think we can just run DCE after all of our lowering but before analyze_boolean_resolves.</div><div><br></div><div>--Jason</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> On July 3, 2018 00:26:32 "Ian Romanick" <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>> wrote:<br>
> <br>
>> From: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a>><br>
>><br>
>> Previously, shader-db runs on Gen5 through Haswell would spew tons of<br>
>> messages like:<br>
>><br>
>>    VS instruction not yet implemented by NIR->vec4<br>
>><br>
>> I checked several instance of this, and all of them were<br>
>> nir_instr_type_deref instructions in vertex shaders that had texture<br>
>> accesses (e.g., UnrealEngine4/EffectsCaveDemo/<wbr>239.shader_test).<br>
>><br>
>> Solution copied directly from fs_visitor::nir_emit_instr.<br>
>><br>
>> Signed-off-by: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a>><br>
>> Fixes: 5a02ffb733e nir: Rework lower_locals_to_regs to use deref<br>
>> instructions<br>
>> Cc: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>><br>
>> ---<br>
>> src/intel/compiler/brw_vec4_<wbr>nir.cpp | 4 ++++<br>
>> 1 file changed, 4 insertions(+)<br>
>><br>
>> diff --git a/src/intel/compiler/brw_vec4_<wbr>nir.cpp<br>
>> b/src/intel/compiler/brw_vec4_<wbr>nir.cpp<br>
>> index 7131fa06b4a..5f45d5b0c98 100644<br>
>> --- a/src/intel/compiler/brw_vec4_<wbr>nir.cpp<br>
>> +++ b/src/intel/compiler/brw_vec4_<wbr>nir.cpp<br>
>> @@ -168,6 +168,10 @@ vec4_visitor::nir_emit_instr(<wbr>nir_instr *instr)<br>
>>       nir_emit_undef(nir_instr_as_<wbr>ssa_undef(instr));<br>
>>       break;<br>
>><br>
>> +   case nir_instr_type_deref:<br>
>> +      /* Derefs can exist for images but they do nothing */<br>
>> +      break;<br>
>> +<br>
>>    default:<br>
>>       fprintf(stderr, "VS instruction not yet implemented by<br>
>> NIR->vec4\n");<br>
>>       break;<br>
>> -- <br>
>> 2.14.4<br>
</div></div></blockquote></div><br></div></div>