[Mesa-dev] [PATCH v2 11/15] i965: Grow the batch/state buffers if we need space and can't flush.

Chris Wilson chris at chris-wilson.co.uk
Thu Sep 14 10:16:00 UTC 2017


Quoting Kenneth Graunke (2017-09-13 21:54:13)
> +/**
> + * Target sizes of the batch and state buffers.  We create the initial
> + * buffers at these sizes, and flush when they're nearly full.  If we
> + * underestimate how close we are to the end, and suddenly need more space
> + * in the middle of a draw, we can grow the buffers, and finish the draw.
> + * At that point, we'll be over our target size, so the next operation
> + * should flush.  Each time we flush the batch, we recreate both buffers
> + * at the original target size, so it doesn't grow without bound.
> + */
>  #define BATCH_SZ (8192*sizeof(uint32_t))
>  #define STATE_SZ (8192*sizeof(uint32_t))
>  
> +/* The kernel assumes batchbuffers are smaller than 256kB. */
> +#define MAX_BATCH_SIZE (256 * 1024)
> +
> +/* 3DSTATE_BINDING_TABLE_POINTERS has a U16 offset from Surface State Base
> + * Address, which means that we can't put binding tables beyond 64kB.  This
> + * effectively limits the maximum statebuffer size to 64kB.
> + */
> +#define MAX_STATE_SIZE (64 * 1024)

> +static void
> +grow_buffer(struct brw_context *brw,
> +            struct brw_bo **bo_ptr,
> +            uint32_t **map_ptr,
> +            uint32_t **cpu_map_ptr,
> +            unsigned existing_bytes,
> +            unsigned new_size)
> +{
> +   struct intel_batchbuffer *batch = &brw->batch;
> +   struct brw_bufmgr *bufmgr = brw->bufmgr;
> +
> +   uint32_t *old_map = *map_ptr;
> +   struct brw_bo *old_bo = *bo_ptr;
> +
> +   struct brw_bo *new_bo = brw_bo_alloc(bufmgr, old_bo->name, new_size, 4096);
> +   uint32_t *new_map;
> +
> +   perf_debug("Growing %s - ran out of space\n", old_bo->name);
> +
> +   /* Copy existing data to the new larger buffer */
> +   if (*cpu_map_ptr) {
> +      *cpu_map_ptr = new_map = realloc(*cpu_map_ptr, new_size);

What I was thinking was for the cpu_map, you know the max size and the
allocation is persistent, so just allocate the max upfront and skip the
realloc (+ implicit copy) of the shadow.
-Chris


More information about the mesa-dev mailing list