[Mesa-dev] [PATCH 1/4] i965: Rework opt_vector_float() control flow.

[Matt Turner]

On Sun, Apr 17, 2016 at 11:14 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> This reworks opt_vector_float() so that there's only one place that
> flushes out any accumulated state and emits a VF.
>
> Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
> ---
>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 63 +++++++++++++++++++---------------
>  1 file changed, 35 insertions(+), 28 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index 6433fc5..fa0d80d 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -385,48 +385,55 @@ vec4_visitor::opt_vector_float()
>     unsigned writemask = 0;
>
>     foreach_block_and_inst_safe(block, vec4_instruction, inst, cfg) {
> -      if (last_reg != inst->dst.nr ||
> +      int vf = -1;
> +
> +      /* Look for unconditional MOVs from an immediate with a partial
> +       * writemask.  See if the immediate can be represented as a VF.
> +       */
> +      if (inst->opcode == BRW_OPCODE_MOV &&
> +          inst->src[0].file == IMM &&
> +          inst->predicate == BRW_PREDICATE_NONE &&
> +          inst->dst.writemask != WRITEMASK_XYZW) {
> +         vf = brw_float_to_vf(inst->src[0].f);
> +      }
> +
> +      /* If this wasn't a MOV, or the value was non-representable, or
> +       * the destination register doesn't match, then this breaks our
> +       * sequence.  Combine anything we've accumulated so far.
> +       */
> +      if (vf == -1 ||

Is the value being non-representable an important point? Running
shader-db on the first three patches shows that something hurt 20
programs, and I think it's considering a non-representable value to
break the sequence.

For instance, in metro-last-light/2175 we see:

-mov(8)          g16<1>.yD       1033476506D
-mov(8)          g16<1>.xzF      [0.375F, 0F, 2.5F, 0F]VF
+mov(8)          g16<1>.xD       1052770304D
+mov(8)          g16<1>.yD       1033476506D
+mov(8)          g16<1>.zD       1075838976D

where the .y component isn't representable but x and z are. I suspect
the other 19 cases are the same problem.