OSDN Git Service

i965: Rework brw_new_batch to actually start a new batch.
authorKenneth Graunke <kenneth@whitecape.org>
Wed, 16 Oct 2013 02:23:53 +0000 (19:23 -0700)
committerKenneth Graunke <kenneth@whitecape.org>
Fri, 15 Nov 2013 18:24:07 +0000 (10:24 -0800)
Previously, brw_new_batch was called just after execbuf, but before
intel_batchbuffer_reset.  Essentially, it prepared for the creation of a
new batch, that wasn't yet available, and which it didn't create.  This
was a bit awkward.

This patch makes brw_new_batch call intel_batchbuffer_reset as the very
first operation.  This means that brw_new_batch actually creates a new
batchbuffer, and thus has it available.  It brings the creation of the
new batchbuffer and BRW_NEW_BATCH flagging together into one place.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
src/mesa/drivers/dri/i965/intel_batchbuffer.c

index 9cdbe9e..fb0b45b 100644 (file)
@@ -178,6 +178,9 @@ do_batch_dump(struct brw_context *brw)
 static void
 brw_new_batch(struct brw_context *brw)
 {
+   /* Create a new batchbuffer and reset the associated state: */
+   intel_batchbuffer_reset(brw);
+
    /* If the kernel supports hardware contexts, then most hardware state is
     * preserved between batches; we only need to re-emit state that is required
     * to be in every batch.  Otherwise we need to re-emit all the state that
@@ -286,7 +289,6 @@ do_flush_locked(struct brw_context *brw)
       fprintf(stderr, "intel_do_flush_locked failed: %s\n", strerror(-ret));
       exit(1);
    }
-   brw_new_batch(brw);
 
    return ret;
 }
@@ -339,9 +341,8 @@ _intel_batchbuffer_flush(struct brw_context *brw,
       drm_intel_bo_wait_rendering(brw->batch.bo);
    }
 
-   /* Reset the buffer:
-    */
-   intel_batchbuffer_reset(brw);
+   /* Start a new batch buffer. */
+   brw_new_batch(brw);
 
    return ret;
 }