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@xxxxxxxxxxxxxxx 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
