As it turns out, we were over-thinking the cause of the hang on
Cherryview. It's simply errata for Cherryview.
commit
88fea85f09e2252035bec66ab26c375b45b000f5
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Fri Nov 21 10:47:41 2014 -0800
i965/vec4/gen8: Handle the MUL dest hazard exception
This is an explanation to why we never saw the hang on BDW.
NOTE: The problem the original patch was trying to fix does still exist. It will
have to be fixed at some point.
v2: Modify commit message, s/CHV/BDW
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84212
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(reg.type == BRW_REGISTER_TYPE_UD || \
reg.type == BRW_REGISTER_TYPE_D)
- /* From the destination hazard section of the spec:
- * > Instructions other than send, may use this control as long as operations
- * > that have different pipeline latencies are not mixed.
+ /* "When source or destination datatype is 64b or operation is integer DWord
+ * multiply, DepCtrl must not be used."
+ * May apply to future SoCs as well.
*/
- if (brw->gen >= 8) {
+ if (brw->is_cherryview) {
if (inst->opcode == BRW_OPCODE_MUL &&
IS_DWORD(inst->src[0]) &&
IS_DWORD(inst->src[1]))