[Mesa-dev] [PATCH 1/3] i965: Avoid kernel BUG_ON if we happen to wait on the pipe_control w/a BO.

Kenneth Graunke kenneth at whitecape.org
Tue Jul 19 22:13:23 PDT 2011


On 07/19/2011 03:44 PM, Eric Anholt wrote:
> For this and occlusion queries, we're trying to avoid setting
> I915_GEM_DOMAIN_RENDER for the write domain, because the data written
> is definitely not going through the render cache, but we do need to
> tell the kernel that the object has been written.  However, with using
> I915_GEM_DOMAIN_GTT, the kernel on retiring the batchbuffer sees that
> the w/a BO has a write domain of GTT, and puts it on the flushing
> list.  If something tries to wait for that BO to finish rendering
> (such as the AUB dumper reading the contents of BOs), we get into
> wait_request (since obj->active) but with a 0 seqno (since the object
> is on the flushing list, not actually on a ringbuffer), and BUG_ONs.
> 
> To avoid the kernel bug (which I'm hoping to delete soon anyway), just
> use I915_GEM_DOMAIN_INSTRUCTION like occlusion queries do.  This
> doesn't result in more flushing, because we invalidate INSTRUCTION on
> every batchbuffer now that we're state streaming, anyway.
> ---
>  src/mesa/drivers/dri/intel/intel_batchbuffer.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> index b61a2ff..9c97ef2 100644
> --- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> @@ -325,7 +325,7 @@ intel_emit_post_sync_nonzero_flush(struct intel_context *intel)
>     OUT_BATCH(_3DSTATE_PIPE_CONTROL);
>     OUT_BATCH(PIPE_CONTROL_WRITE_IMMEDIATE);
>     OUT_RELOC(intel->batch.workaround_bo,
> -	     I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT, 0);
> +	     I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION, 0);
>     OUT_BATCH(0); /* write data */
>     ADVANCE_BATCH();

For this patch only:

Reviewed-and-tested-by: Kenneth Graunke <kenneth at whitecape.org>


More information about the mesa-dev mailing list