[Intel-gfx] [PATCH 14/15] drm/i915: Track frontbuffer invalidation/flushing
Chris Wilson
chris at chris-wilson.co.uk
Tue Jun 17 09:40:10 CEST 2014
On Tue, Jun 17, 2014 at 09:37:35AM +0200, Daniel Vetter wrote:
> On Tue, Jun 17, 2014 at 07:50:45AM +0100, Chris Wilson wrote:
> > On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> > > @@ -2227,6 +2223,9 @@ i915_gem_object_move_to_inactive(struct drm_i915_gem_object *obj)
> > > list_move_tail(&vma->mm_list, &vm->inactive_list);
> > > }
> > >
> > > + if (obj->frontbuffer_bits)
> > > + intel_fb_flush(obj, true);
> > > +
> > > list_del_init(&obj->ring_list);
> > > obj->ring = NULL;
> > >
> > > @@ -3556,6 +3555,8 @@ i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object *obj)
> > > old_write_domain = obj->base.write_domain;
> > > obj->base.write_domain = 0;
> > >
> > > + intel_fb_flush(obj, false);
> > > +
> > I think it is worth the if (obj->frontbuffer_bit) check everywhere.
>
> Well it's the first thing fb_flush checks, so the additional ones are just
> stupid micro-optimizations I guess. Should I remove them everywhere?
Yes. The most frequent of these would be in execbuffer, so perhaps keep
that one. But the rest are equally in the noise.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list