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: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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
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