isl: Don't set UnormPathInColorPipe for integer surfaces.

This fixes dEQP-GLES3.functional.texture.specification subtests on iris:

- texsubimage3d_depth.depth24_stencil8_2d_array
- texsubimage3d_depth.depth32f_stencil8_2d_array
- texsubimage3d_depth.depth_component32f_2d_array
- texsubimage3d_depth.depth_component24_2d_array
- texstorage2d.format.depth24_stencil8_2d
- texstorage2d.format.depth32f_stencil8_2d
- texstorage2d.format.depth_component24_2d
- texstorage2d.format.depth_component32f_2d
- texstorage3d.format.depth24_stencil8_2d_array
- texstorage3d.format.depth32f_stencil8_2d_array
- texstorage3d.format.depth_component24_2d_array
- texstorage3d.format.depth_component32f_2d_array

Here, something appears to be going wrong with having this bit set
during blorp_copy operations for texture upload, which override the
format to R8G8B8A8_UINT.

AFAICT this bit should have no effect for integer surfaces, as it has
to do with blending, and integer blending is not a thing.  So it should
be harmless to disable it.

The Windows driver appears to be setting this bit universally, so
I am unclear why we would need to.  Perhaps they simply haven't run
into this issue.

Fixes: f741de236b ("isl: Enable Unorm Path in Color Pipe")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
(cherry picked from commit 2e1be771e4)

src/intel/isl/isl_surface_state.c

@@ -455,7 +455,12 @@ isl_genX(surf_fill_state_s)(const struct isl_device *dev, void *state,
 #endif
 
 #if GEN_GEN >= 11
-   s.EnableUnormPathInColorPipe = true;
+   /* We've seen dEQP failures when enabling this bit with UINT formats,
+    * which particularly affects blorp_copy() operations.  It shouldn't
+    * have any effect on UINT textures anyway, so disable it for them.
+    */
+   s.EnableUnormPathInColorPipe =
+      !isl_format_has_int_channel(info->view->format);
 #endif
 
    s.CubeFaceEnablePositiveZ = 1;