intel/compiler: fix brw_imm_w for negative 16-bit integers
authorJose Maria Casanova Crespo <jmcasanova@igalia.com>
Wed, 2 May 2018 23:38:47 +0000 (01:38 +0200)
committerIago Toral Quiroga <itoral@igalia.com>
Thu, 3 May 2018 09:40:25 +0000 (11:40 +0200)
commitf0e6dacee529661393964725bed561c45405bae4
tree3978d7e6f6d3bf1507a985cc91c2204e1596d4d3
parent2a76f03c90037a8966eeb7e47d86c11a6ada9312
intel/compiler: fix brw_imm_w for negative 16-bit integers

16-bit immediates need to replicate the 16-bit immediate value
in both words of the 32-bit value. This needs to be careful
to avoid sign-extension, which the previous implementation was
not handling properly.

For example, with the previous implementation, storing the value
-3 would generate imm.d = 0xfffffffd due to signed integer sign
extension, which is not correct. Instead, we should cast to
uint16_t, which gives us the correct result: imm.ud = 0xfffdfffd.

We only had a couple of cases hitting this path in the driver
until now, one with value -1, which would work since all bits are
one in this case, and another with value -2 in brw_clip_tri(),
which would hit the aforementioned issue (this case only affects
gen4 although we are not aware of whether this was causing an
actual bug somewhere).

v2: Make explicit uint32_t casting for left shift (Jason Ekstrand)

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "18.0 18.1" <mesa-stable@lists.freedesktop.org>
src/intel/compiler/brw_reg.h