On Thu, May 28, 2015 at 02:24:40PM +0200, Daniel Vetter wrote: > On Thu, May 28, 2015 at 09:58:30AM +0100, Tvrtko Ursulin wrote: > > > > On 05/27/2015 10:15 PM, Chris Wilson wrote: > > >On Wed, May 27, 2015 at 10:52:34AM +0100, Tvrtko Ursulin wrote: > > >>From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > >> > > >>These are the display call sites so should use the proper helper. > > >> > > >>Also requires intel_plane_obj_offset to assume normal view when > > >>plane pointer is not available. > > > > > >Eugh. If only the plane stored the offset, bonus marks for storing the > > >vma cookie, then we would not have to keep recomputing the view and > > >searching every single time... > > > > Well, the patch even decreases the number of searches! :) > > > > And we don't recompute when querying the offset - it just figures out what > > type of vma it should look for. So I think it doesn't prevent any future > > caching improvements. It actually makes it easier since it consolidates the > > query. > > > > I'll need this, or something like it, for some future work. So at the very > > moment I am not too bothered if this goes in or not. > > Yeah unfortunately we can't eliminate the view searches completely since > the view depends upon fb + plane_state. So not perfectly aligned with our > hw ... Otherwise I'd agree, caching the view in the fb would be neat. Not in the fb, in the plane_state. We acquire the vma for the plane during prepare and then we should be using that vma reference for the lifetime of that atomic plane state. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
