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@xxxxxxxxxxxxxxxxxx> 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@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
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
