Re: [PATCH 14/15] drm/i915: Track frontbuffer invalidation/flushing

Chris Wilson
2014-06-17T07:42:37Z

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