Message ID | 1394140352-1307-1-git-send-email-kenneth@whitecape.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Thu, Mar 06, 2014 at 01:12:30PM -0800, Kenneth Graunke wrote: > The first call to BEGIN_BATCH or BEGIN_BATCH_BLT will set current_batch > to RENDER_BATCH or BLT_BATCH. If it's zero, that means the batch is > empty, so there's no point in flushing. > > Previously, we would just go ahead and do a RENDER_RING flush, though > more by accident than intentional design. It was intentional. One code path required us to emit an empty batch - except that we don't allow such and so had to emit a flush instead. -Chris
diff --git a/src/uxa/intel_batchbuffer.c b/src/uxa/intel_batchbuffer.c index 579a63a..ca1af0d 100644 --- a/src/uxa/intel_batchbuffer.c +++ b/src/uxa/intel_batchbuffer.c @@ -184,6 +184,10 @@ void intel_batch_emit_flush(ScrnInfoPtr scrn) assert (!intel->in_batch_atomic); + /* No point in flushing an empty batch. */ + if (intel->current_batch == 0) + return; + /* Big hammer, look to the pipelined flushes in future. */ if ((INTEL_INFO(intel)->gen >= 060)) { if (intel->current_batch == BLT_BATCH) {
The first call to BEGIN_BATCH or BEGIN_BATCH_BLT will set current_batch to RENDER_BATCH or BLT_BATCH. If it's zero, that means the batch is empty, so there's no point in flushing. Previously, we would just go ahead and do a RENDER_RING flush, though more by accident than intentional design. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> --- src/uxa/intel_batchbuffer.c | 4 ++++ 1 file changed, 4 insertions(+)