On 03/20/2015 10:58 PM, Ian Romanick wrote:
From: Ian Romanick <ian.d.roman...@intel.com>
With previous changes to emit more ir_triop_csel, the i965 channel
expressions pass can generate sequences like:
mov(8) g45<1>F 1F
(+f0) sel(8) g40<1>F g45<8,8,1>F 1F
There are no shader-db changes now, but this prevents a large number of
regressions from a later commit (glsl: Optimize certain if-statements to
ir_triop_csel).
Signed-off-by: Ian Romanick <ian.d.roman...@intel.com>
Cc: Tapani Pälli <tapani.pa...@intel.com>
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index e39dab3..1fbef5f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -708,6 +708,15 @@ fs_visitor::visit(ir_expression *ir)
break;
case ir_triop_csel:
+ /* After splitting an expression like 'v = csel(cond, vec4(a, b, c, 1),
+ * vec4(d, e, f, 1))', there will be a 'v.w = csel(cond, 1, 1)'. Detect
+ * this, and avoid emitting the spurious SEL.
+ */
+ if (ir->operands[1]->equals(ir->operands[2])) {
+ ir->operands[1]->accept(this);
+ return;
The result is correct but why is this done in the backend? Couldn't the
later commit mentioned for glsl already detect this or maybe additional
optimization pass there?
+ }
+
if (try_opt_frontfacing_ternary(ir))
return;
// Tapani
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev