mov takes only a single source argument. Example instruction
inexplicably changed from add to mov in commit f10f5e49.
---
src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
index fa84c55..a29767d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
@@ -64,18 +64,18 @@ fs_live_variables::setup_one_read(bblock_t *block, fs_inst
*inst,
* destination starts (naturally). This gets more complicated for
* simd16, because the instruction:
*
- * mov(16) g4<1>F g4<8,8,1>F g6<8,8,1>F
+ * add(16) g4<1>F g4<8,8,1>F g6<8,8,1>F
*
* is actually decoded in hardware as:
*
- * mov(8) g4<1>F g4<8,8,1>F g6<8,8,1>F
- * mov(8) g5<1>F g5<8,8,1>F g7<8,8,1>F
+ * add(8) g4<1>F g4<8,8,1>F g6<8,8,1>F
+ * add(8) g5<1>F g5<8,8,1>F g7<8,8,1>F
*
* Which is safe. However, if we have uniform accesses
* happening, we get into trouble:
*
- * mov(8) g4<1>F g4<0,1,0>F g6<8,8,1>F
- * mov(8) g5<1>F g4<0,1,0>F g7<8,8,1>F
+ * add(8) g4<1>F g4<0,1,0>F g6<8,8,1>F
+ * add(8) g5<1>F g4<0,1,0>F g7<8,8,1>F
*
* Now our destination for the first instruction overwrote the
* second instruction's src0, and we get garbage for those 8
--
1.8.3.2
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
