[Intel-gfx] [CI 1/6] drm/i915: Remove temporary allocation of dma addresses when rotating

[Chris Wilson]

On Mon, Feb 20, 2017 at 10:36:33AM +0000, Tvrtko Ursulin wrote:
> 
> On 17/02/2017 16:37, Chris Wilson wrote:
> >On Fri, Feb 17, 2017 at 04:28:13PM +0000, Tvrtko Ursulin wrote:
> >>
> >>On 17/02/2017 15:12, Chris Wilson wrote:
> >>>The object already stores (computed on the fly) the index to dma address
> >>>so use it instead of reallocating a large temporary array every time we
> >>>bind a rotated framebuffer.
> >>
> >>On the other hand how big is the radix tree for a large framebuffer?
> >>I remember those nodes were quite chunky and will hang around for
> >>the lifetime of the object. While the above mentioned large
> >>temporary array needs to be allocated only if rotated VMAs have been
> >>discarded due GGTT pressure, no?
> >>
> >>On the other other hand maybe the radix tree won't be so big in the
> >>typical case, due sg entry coalescing, but it will hang around for
> >>much longer.
> >
> >Also don't forget that we use the radixtree for mmaps, partials, single
> >page lookups. In all likelihood it already exists, and it doesn't hang
> >around forever.
> 
> Yeah, but for a typical framebuffer none of this are actually used
> to trigger creating the radix tree.
> 
> For a standard 1920x1080x32 fb, temporary allocation for rotation is
> only ~16KiB so don't see that it can cause any problems even with 4k
> screens.
> 
> Struct radix_tree_node is much chunkier so how many of those will a
> typical framebuffer need and how much memory in total would it tie
> up? It would only be dropped once we drop the backing store, so for
> framebuffers basically never.

Typically? We're talking about how often do people do GTT mmaps even
though we keep telling them not to?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre