i965/fs: Unpack count argument to 64-bit shift ops on Atom
authorMatt Turner <mattst88@gmail.com>
Thu, 21 Sep 2017 23:42:02 +0000 (16:42 -0700)
committerMatt Turner <mattst88@gmail.com>
Wed, 4 Oct 2017 21:08:54 +0000 (14:08 -0700)
commitb541945c2027990ac571184bbf8e01285be0e33a
treeb36bebb4f41890fa8146cc0c3f4cc635c75009d0
parent2082c32950a9e3a4debc00b0d6da85404b923920
i965/fs: Unpack count argument to 64-bit shift ops on Atom

64-bit operations on Atom parts have additional restrictions over their
big-core counterparts (validated by later patches).

Specifically, the restriction that "Source and Destination horizontal
stride must be aligned to the same qword" is violated by most shift
operations since NIR uses a 32-bit value as the shift count argument,
and this causes instructions like

   shl(8)          g19<1>Q         g5<4,4,1>Q      g23<4,4,1>UD

where src1 has a 32-bit stride, but the dest and src0 have a 64-bit
stride.

This caused ~4 pixels in the ARB_shader_ballot piglit test
fs-readInvocation-uint.shader_test to be incorrect. Unfortunately no
ARB_gpu_shader_int64 test hit this case because they operate on
uniforms, and their scalar regions are an exception to the restriction.

We work around this by effectively unpacking the shift count, so that we
can read it with a 64-bit stride in the shift instruction. Unfortunately
the unpack (a MOV with a dst stride of 2) is a partial write, and cannot
be copy-propagated or CSE'd.

Bugzilla: https://bugs.freedesktop.org/101984
src/intel/compiler/brw_fs_nir.cpp