[Intel-gfx] [PATCH v3 06/10] drm/i915: Implement LRI based FBC tracking

[Chris Wilson]

On Wed, Nov 20, 2013 at 02:55:57PM -0800, Rodrigo Vivi wrote:
> On Wed, Nov 06, 2013 at 11:02:21PM +0200, ville.syrjala at linux.intel.com wrote:
> >  static void
> > +i915_gem_execbuffer_mark_fbc_dirty(struct intel_ring_buffer *ring,
> > +				   struct list_head *vmas)
> > +{
> > +	struct i915_vma *vma;
> > +	struct drm_i915_gem_object *fbc_obj = NULL;
> > +	u32 fbc_address = -1;
> > +
> > +	list_for_each_entry(vma, vmas, exec_list) {
> > +		struct drm_i915_gem_object *obj = vma->obj;
> > +
> > +		if (obj->base.pending_write_domain &&
> > +		    intel_fb_obj_has_fbc(obj)) {
> > +			WARN_ON(fbc_obj && fbc_obj != obj);
> > +			fbc_obj = obj;
> > +		}
> > +	}
> > +
> > +	if (fbc_obj)
> > +		fbc_address = i915_gem_obj_ggtt_offset(fbc_obj);
> > +
> > +	/* need to nuke/cache_clean on IVB+? */
> > +	ring->fbc_dirty = fbc_obj != NULL;
> > +
> > +	/* need to update FBC tracking? */
> > +	ring->fbc_address_dirty = fbc_address != ring->fbc_address;
> > +	ring->fbc_address = fbc_address;

There's a risk here that we restart the execbuffer and on the second
pass we no longer treat the fbc_address as requiring an update.
ring->fb_address_dirty |= fbc_address != ring->fbc_address
wins for paranoia, and also makes the ordering with set_context a
non-issue.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre