[Mesa-dev] [PATCH 2/2] i965: run brw_vec4 optimizations in loop

[Juan A. Suarez Romero]

On Wed, 2015-11-25 at 16:16 -0800, Matt Turner wrote:
> I had a look at a helped shader from shader-db (borderlands-2/3701)
> 
> Its vec4 IR at the time we call opt_vector_float() contains:
> 
>    0: mov vgrf2.0.x:D, 1073741824D
>    1: mov vgrf3.0.xy:D, 0D
>    2: mov vgrf3.0.w:D, 1065353216D
>    3: mov vgrf4.0.xy:D, 1065353216D
>    4: mov vgrf4.0.w:D, 0D
> 
> The .z component of vgrf3 and vgrf4 isn't completely dead, so the
> opt_vector_float() pass doesn't handle them because it cannot find
> writes to all 4 components. By moving opt_vector_float() into the
> main
> optimization loop, we simply get lucky that the .z channel hasn't yet
> been eliminated and so it makes progress.
> 
> I strongly suspect the other cases in shader-db have the same
> problem.
> 
> I think in this case a better solution -- at least until we learn
> something more -- would be to initialize opt_vector_float()'s
> remaining_channels to only the live components of the register. Do
> you
> want to try that?


So finally I tried a similar approach as you suggested: apply
opt_vector_float() whenever is possible, with the components written,
using writemask to select the proper ones.


Now the results I get regarding master (commit 56aff6bb4eaf) are even
better:

    total instructions in shared programs: 6819484 -> 6811698 (-0.11%)
    instructions in affected programs:     387245 -> 379459 (-2.01%)
    total loops in shared programs:        1971 -> 1971 (0.00%)
    helped:                                3980
    HURT:                                  0
    GAINED:                                3
    LOST:                                  0


Indeed, your solution is quite better :)

Also, I tried to combine this approach with the original submitted, to
see if further improvement can be obtained. But didn't get better
results, so I'm going to push this new patch replacing the (two)
original ones sent.


	J.A.