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

[Rodrigo Vivi]

ops, I just noticed that by mistake I replied the v1-series....
but I actually looked to v2 seires... Sorry about that

On Wed, Nov 20, 2013 at 3:17 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 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



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br