isl: Don't set UnormPathInColorPipe for integer surfaces.
authorKenneth Graunke <kenneth@whitecape.org>
Sat, 24 Aug 2019 00:32:06 +0000 (17:32 -0700)
committerKenneth Graunke <kenneth@whitecape.org>
Mon, 26 Aug 2019 16:54:20 +0000 (16:54 +0000)
commit2e1be771e47adf1d06901283ffb8df0d83f28b3c
tree645b6b316d16e223d845065fbc295d1e526dca73
parent1b090f065e0f39856ef4b228091f76241f1bbe2b
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: f741de236b5 ("isl: Enable Unorm Path in Color Pipe")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
src/intel/isl/isl_surface_state.c