On Mon, Nov 16, 2015 at 11:00 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On Sat, Nov 14, 2015 at 6:59 PM, Connor Abbott <cwabbo...@gmail.com> wrote:
>> Shader-db results on bdw with INTEL_DEBUG=vec4:
>>
>> total instructions in shared programs: 1634044 -> 1612936 (-1.29%)
>> instructions in affected programs: 802502 -> 781394 (-2.63%)
>> helped: 5036
>> HURT: 1442
>>
>> total cycles in shared programs: 9397790 -> 9355382 (-0.45%)
>> cycles in affected programs: 5078600 -> 5036192 (-0.84%)
>> helped: 3875
>> HURT: 2554
>>
>> LOST: 0
>> GAINED: 0
>>
>> Most of the hurt programs seem to be because we generate extra MOV's due
>> to vectorizing things. For example, in
>> shaders/non-free/steam/anomaly-2/158.shader_test, this:
>>
>> add(8) g116<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.xyyyF { align16
>> NoDDClr 1Q };
>> add(8) g117<1>.xyF g12<4,4,1>.xyyyF g1.4<0,4,1>.zwwwF { align16
>> NoDDClr 1Q };
>> add(8) g116<1>.zwF g12<4,4,1>.xxxyF -g1.4<0,4,1>.xxxyF {
>> align16 NoDDChk 1Q };
>> add(8) g117<1>.zwF g12<4,4,1>.xxxyF -g1.4<0,4,1>.zzzwF {
>> align16 NoDDChk 1Q };
>>
>> Turns into this:
>>
>> add(8) g13<1>F g12<4,4,1>.xyxyF g1.4<0,4,1>F { align16 1Q
>> };
>> add(8) g14<1>F g12<4,4,1>.xyxyF -g1.4<0,4,1>F { align16 1Q
>> };
>> mov(8) g116<1>.xyD g13<4,4,1>.xyyyD { align16
>> NoDDClr 1Q };
>> mov(8) g117<1>.xyD g13<4,4,1>.zwwwD { align16
>> NoDDClr 1Q };
>> mov(8) g116<1>.zwD g14<4,4,1>.xxxyD { align16
>> NoDDChk 1Q };
>> mov(8) g117<1>.zwD g14<4,4,1>.zzzwD { align16
>> NoDDChk 1Q };
>>
>> So we eliminated two add's, but then had to introduce four mov's to
>> transpose the result. I don't think there's much we can do about this at
>> the NIR level, unfortunately.
>
> Given the shader-db numbers above, I think we can probably eat the
> hurt programs. Would you mind cherry-picking back onto a time when we
> had GLSL IR and doing a GLSL IR vs. NIR comparison with this series?
> This is one of the places we were still hurting so it would be good to
> know how it changes the picture. Not that it *really* matters at this
> point...
So I rebased the series onto right before we switched to NIR by
default. For non-NIR vs. NIR, the numbers were:
total instructions in shared programs: 1848629 -> 1647133 (-10.90%)
instructions in affected programs: 1663319 -> 1461711 (-12.12%)
total loops in shared programs: 223 -> 222 (-0.45%)
helped: 14667
HURT: 1416
GAINED: 0
LOST: 0
and for non-NIR vs. NIR + vectorization:
total instructions in shared programs: 1848629 -> 1619388 (-12.40%)
instructions in affected programs: 1696613 -> 1467260 (-13.52%)
total loops in shared programs: 223 -> 222 (-0.45%)
helped: 15076
HURT: 1378
GAINED: 0
LOST: 0
so, indeed, it does seem to get rid of some hurt programs. My
suspicion, though, is that it's a case of "well, NIR hurt, but the
gain from vectorizing offset the (unrelated) problem so that now it
helps." We don't ever split up vectorized operations in NIR (except
when lowering to scalar, ofc) so NIR shouldn't be doing anything
harmful that this pass would help.
>
>> Signed-off-by: Connor Abbott <cwabbo...@gmail.com>
>> ---
>> src/mesa/drivers/dri/i965/brw_nir.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_nir.c
>> b/src/mesa/drivers/dri/i965/brw_nir.c
>> index fe5cad4..29cafe6 100644
>> --- a/src/mesa/drivers/dri/i965/brw_nir.c
>> +++ b/src/mesa/drivers/dri/i965/brw_nir.c
>> @@ -198,6 +198,14 @@ nir_optimize(nir_shader *nir, bool is_scalar)
>> nir_validate_shader(nir);
>> progress |= nir_opt_cse(nir);
>> nir_validate_shader(nir);
>> +
>> + if (!is_scalar) {
>> + progress |= nir_opt_vectorize(nir);
>> + nir_validate_shader(nir);
>> + progress |= nir_copy_prop(nir);
>> + nir_validate_shader(nir);
>> + }
>> +
>> progress |= nir_opt_peephole_select(nir);
>> nir_validate_shader(nir);
>> progress |= nir_opt_algebraic(nir);
>> --
>> 2.4.3
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
