[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