While GLSL restricts bitfieldInsert's offset and bits parameters to
be scalars, we shouldn't require this in the IR.
In particular, opt_vectorize() tries to combine
result.x = bitfieldInsert(src0.x, src1.x, src2.x, src3.x);
result.y = bitfieldInsert(src0.y, src1.y, src2.y, src3.y);
result.z = bitfieldInsert(src0.z, src1.z, src2.z, src3.z);
result.w = bitfieldInsert(src0.w, src1.w, src2.w, src3.w);
into a single ivec4 bitfieldInsert operation. This currently breaks,
because the last two types become ivec4 rather than int. It seems
perfectly reasonable to allow this.
i965 lowers ir_quadop_bitfield_insert to ir_binop_bfm and ir_triop_bfi,
which already lift these restrictions.
(I debated about using is_integer() or base_type == GLSL_TYPE_INT here;
I ended up relaxing it to allow either int/uint because ir_binop_bfm
and ir_triop_bfi do that already.)
Fixes assertion failures when compiling Shadow of Mordor vertex shaders
on i965 in vec4 mode (where OptimizeForAOS enables opt_vectorize()).
Signed-off-by: Kenneth Graunke <kenn...@whitecape.org>
Cc: Matt Turner <matts...@gmail.com>
Cc: mesa-sta...@lists.freedesktop.org
---
src/glsl/ir_validate.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index dcc079c..b5eaaff 100644
--- a/src/glsl/ir_validate.cpp
+++ b/src/glsl/ir_validate.cpp
@@ -661,8 +661,8 @@ ir_validate::visit_leave(ir_expression *ir)
case ir_quadop_bitfield_insert:
assert(ir->operands[0]->type == ir->type);
assert(ir->operands[1]->type == ir->type);
- assert(ir->operands[2]->type == glsl_type::int_type);
- assert(ir->operands[3]->type == glsl_type::int_type);
+ assert(ir->operands[2]->type->is_integer());
+ assert(ir->operands[3]->type->is_integer());
break;
case ir_quadop_vector:
--
2.6.4
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
