>My worry is that batch->bo is not constant for the construction of a single
>execbuf2.
> If intel_batchbuffer.c runs out of room inside the batch->bo, it will
> allocate a new one and continue building it.
That will be ok, but if the (fd, GEM BO handle) changes, there is a serious
issue.
> I
Quoting Rogovin, Kevin (2017-09-27 15:22:00)
> Hi,
>
> > Hmm, this needs updating for the batch/state split;
>
> This was rebased (and working) against Mesa of Monday, Sept 25, 2017, which I
> thought already had the batchbuffer split. I had thought the split was
> already in master... but why
Quoting kevin.rogo...@intel.com (2017-09-25 11:34:06)
> +static
> +uint32_t
> +intel_batchbuffer_state(const struct i965_logged_batchbuffer *st)
> +{
> + struct intel_batchbuffer *batch
> + = (struct intel_batchbuffer*) st->driver_data;
> +
> + assert(batch->bo->gem_handle == st->gem_bo);
From: Kevin Rogovin
The interface for BatchbufferLogger is that it is active
only if it is LD_PRELOAD'ed. Thus, the i965 driver is to
use dlsym to see if it is there, and if so fetch the object
at intel_screen creation.
Signed-off-by: Kevin Rogovin
---
src/mesa/drivers/dri/i965/brw_bufmgr.c
