On Friday, February 27, 2015 10:22:10 AM Ben Widawsky wrote: > From the comments in the code: > > Called from intel_batchbuffer_flush before emitting MI_BATCHBUFFER_END and > sending it off. > > This fixes a possible, unlikely infinite recursion in our batch flush path. > More > importantly it allows me to add some code here. > > The relevant part of the call chain for flush > intel_batchbuffer_flush()->brw_finish_batch(). The problem arises if anything > in > the time from intel_batchbuffer_flush, until brw_finish_batch ends up calling > itself. This can happen as a result of a call to > intel_batchbuffer_begin()->intel_batchbuffer_require_space()->intel_batchbuffer_flush(). > > There are two possible cases today which can spawn this recursion. > 1. There is a ring switch occurring (impossible, see below) > 2. The ring is out of space (fairly unlikely)
NAK. brw_finish_batch is for putting any last-minute commands in the batchbuffer before sending it off. Such commands must fit in the BATCH_RESERVED space (which is probably already large enough since SNB has a zillion workarounds). This eliminates reason #2. #1 means that you're trying to emit commands for the wrong ring, i.e. trying to do RCS workarounds in a BLT batch. This isn't what you want.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
