[Mesa-dev] [PATCH 4/4] i965: Properly handle integer types in opt_vector_float().

[Matt Turner]

On Sun, Apr 17, 2016 at 11:14 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> Previously, opt_vector_float() always interpreted MOV sources as
> floating point, and always created a MOV with a F-type destination.
>
> This meant that we could mess up sequences of integer loads, such as:
>
>    mov vgrf6.0.x:D, 0D
>    mov vgrf6.0.y:D, 1D
>    mov vgrf6.0.z:D, 2D
>    mov vgrf6.0.w:D, 3D
>
> Here, integer 0/1/2/3 become approximately 0.0f, so we generated:
>
>    mov vgrf6.0:F, [0F, 0F, 0F, 0F]
>
> which is clearly wrong.  We can properly handle this by converting
> integer values to float (rather than bitcasting), and emitting a type
> converting MOV:
>
>    mov vgrf6.0:D, [0F, 1F, 2F, 3F]
>
> To do this, see first see if the integer values (converted to float)
> are representable.  If so, we use a D-type MOV.  If not, we then try
> the floating point values and an F-type MOV.  We make zero not impose
> type restrictions.  This is important because 0D would imply a D-type
> MOV, but is often used in sequences such as MOV 0D, MOV 0x3f800000D,
> where we want to use an F-type MOV.
>
> Fixes about 54 dEQP-GLES2 failures with the vec4 VS backend.  This
> recently became visible due to changes in opt_vector_float() which
> made it optimize more cases, but it was a pre-existing bug.
>
> Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>

Hurts a single program in shader-db... for some reason related to
seeing a zero first?

In toki-tori-2/1, we see

-mov(8)          g18<1>.zwF      [0F, 0F, 0F, 1F]VF
+mov(8)          g18<1>.zUD      0x00000000UD
+mov(8)          g18<1>.wD       1065353216D

Ignore the UD type -- the generator changes D -> UD so it can compact
the instruction. It's actually type-D when opt_vector_float is called.