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 <kenn...@whitecape.org> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
