Re: [PATCH] drm/i915: Disable shrinker for non-swapped backed objects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 26, 2015 at 10:30:57AM +0000, Chris Wilson wrote:
> On Thu, Nov 26, 2015 at 10:34:51AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 25, 2015 at 09:58:28AM +0000, Chris Wilson wrote:
> > > One thing I did notice when also dealing with memory
> > > pressure flushing backbuffers was (a) they were unaligned and so needed
> > > rebinding before pinning
> > > http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=df636036d120c6227d1918cfd6d70232d8d37b4c
> > 
> > Not sure I read this correctly, but shouldn't we cache the alignment for
> > as long as the buffer isn't purged? Your patch resets when we unpin the
> > last display user. So in your scenario above that could result in an
> > unaligned rebinding for GT first, then aligned rebinding for display. I
> > figured the idea is to get things right for the render right away?
> 
> It was focused on the solving the problem that scanout needed to realign
> the buffer. I felt that keeping the maximum alignment imposed by the
> user was just asking for trouble. (It's actually a bug in that patch
> that the alignment is reset there, it should be when
> framebuffer_references drops to zero. Also note that is depends upon the
> vma being persistent until closed.)
> 
> > Only risk is that we might overalign things, but that only happens when
> > userspace reuses fbs and non-fbs in a mixed fashion. But that shouldn't be
> > a real problem I think.
> 
> Probably not, just I don't trust them! The goal is keep the maximum
> restriction for only as long as it makes sense. We want relaxed fenced
> layout (because space is at a scarce resource on that hw), so always
> binding a tiled object at its max alignment is counter productive.
> framebuffers are typically only created for as long as required (give or
> take a small amount of caching, either in the flip-sequence or by a
> timer on idle). So keeping the fb's vma aligned seems a worthwhile
> tradeoff to avoid having to rebind it just as we want to present it to
> the screen. We have no time bounds on the user alignment, so that will
> seem to be always at odds with reducing the alignment for improved packing
> at the earliest opportunity.
> 
> I'm pretty certain that fb alignment is the only restriction we wish to
> keep.

Yeah, keeping fb alignment until fb_refs drops to 0 makes sense.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux