[Intel-gfx] [PATCH 14/15] drm/i915: Track frontbuffer invalidation/flushing

[Chris Wilson]

On Tue, Jun 17, 2014 at 08:40:10AM +0100, Chris Wilson wrote:
> 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.

Equally, move-to-inactive. Slightly less hit than execbuffer, but often
enough to make me concerned.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre