gallium/tgsi: Treat UCMP sources as floats to match the GLSL-to-TGSI pass expectations.
authorFrancisco Jerez <currojerez@riseup.net>
Tue, 14 Mar 2017 00:31:39 +0000 (17:31 -0700)
committerFrancisco Jerez <currojerez@riseup.net>
Wed, 15 Mar 2017 22:47:14 +0000 (15:47 -0700)
commite6469ec43b25898e99766a30aa8f54cc64c3bc04
treef2a5c93b387478a1e4cff8f3120f3d563347cf46
parenteb5a61f77a551e98b35bd9f4de3e44ed6c98dd1f
gallium/tgsi: Treat UCMP sources as floats to match the GLSL-to-TGSI pass expectations.

Currently the GLSL-to-TGSI translation pass assumes it can use
floating point source modifiers on the UCMP instruction.  See the bug
report linked below for an example where an unrelated change in the
GLSL built-in lowering code for atan2 (e9ffd12827ac11a2d2002a42fa8eb1)
caused the generation of floating-point ir_unop_neg instructions
followed by ir_triop_csel, which is translated into UCMP with a negate
modifier on back-ends with native integer support.

Allowing floating-point source modifiers on an integer instruction
seems like rather dubious design for a transport IR, since the same
semantics could be represented as a sequence of MOV+UCMP instructions
instead, but supposedly this matches the expectations of TGSI
back-ends other than tgsi_exec, and the expectations of the DX10 API.
I take no responsibility for future headaches caused by this
inconsistency.

Fixes a regression of piglit glsl-fs-tan-1 on softpipe introduced by
the above-mentioned glsl front-end commit.  Even though the commit
that triggered the regression doesn't seem to have made it to any
stable branches yet, this might be worth back-porting since I don't
see any reason why the bug couldn't have been reproduced before that
point.

Suggested-by: Roland Scheidegger <sroland@vmware.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99817
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
src/gallium/auxiliary/tgsi/tgsi_exec.c
src/gallium/docs/source/tgsi.rst