Otherwise we end up producing code that violates the register region
restriction that says that when execsize == width and hstride != 0
the vstride can't be 0.
---
src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
index d284528..93c3b0e 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
@@ -329,6 +329,17 @@ try_copy_propagate(const struct brw_device_info *devinfo,
if (devinfo->gen < 8 && inst->regs_written > 1 && is_uniform(value))
return false;
+ /* There is a regioning restriction such that if execsize == width
+ * and hstride != 0 then the vstride can't be 0. When we split instrutions
+ * that take a single-precision source (like F->DF conversions) we end up
+ * with a 4-wide source on an instruction with an execution size of 4.
+ * If we then copy-propagate the source from a uniform we also end up with a
+ * vstride of 0 and we violate the restriction.
+ */
+ if (inst->exec_size == 4 && value.file == UNIFORM &&
+ type_sz(value.type) == 4)
+ return false;
+
/* If the type of the copy value is different from the type of the
* instruction then the swizzles and writemasks involved don't have the same
* meaning and simply replacing the source would produce different
semantics.
--
2.7.4
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
