intel/aubinator: Properly handle batch buffer chaining

The original aubinator that Kristian wrote had a bug in the handling of
MI_BATCH_BUFFER_START that propagated into the version in upstream mesa.
In particular, it ignored the "2nd level" bit which tells you whether this
MI_BATCH_BUFFER_START is a subroutine call (2nd level) or a goto.  Since
the Vulkan driver uses batch chaining, this can lead to a very confusing
interpretation of the batches.  In some cases, depending on how things are
laid out in the virtual GTT, you can even end up with infinite loops in
batch processing.

Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
This commit is contained in:
Jason Ekstrand 2016-09-08 21:12:11 -07:00 committed by Jason Ekstrand
parent 0a5e1b02cf
commit d6cef32047
1 changed files with 19 additions and 1 deletions

View File

@ -790,7 +790,25 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int size, int engine)
else
start = p[1];
parse_commands(spec, gtt + start, 1 << 20, engine);
if (p[0] & (1 << 22)) {
/* MI_BATCH_BUFFER_START with "2nd Level Batch Buffer" set acts
* like a subroutine call. Commands that come afterwards get
* processed once the 2nd level batch buffer returns with
* MI_BATCH_BUFFER_END.
*/
parse_commands(spec, gtt + start, gtt_end - start, engine);
} else {
/* MI_BATCH_BUFFER_START with "2nd Level Batch Buffer" unset acts
* like a goto. Nothing after it will ever get processed. In
* order to prevent the recursion from growing, we just reset the
* loop and continue;
*/
p = gtt + start;
/* We don't know where secondaries end so use the GTT end */
end = gtt + gtt_end;
length = 0;
continue;
}
} else if ((p[0] & 0xffff0000) == AUB_MI_BATCH_BUFFER_END) {
break;
}