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

Chris Wilson chris at chris-wilson.co.uk
Fri Feb 17 16:37:53 UTC 2017


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.

> >-	DRM_DEBUG_KMS("Created rotated page mapping for object size %zu (%ux%u tiles, %u pages)\n",
> >-		      obj->base.size, rot_info->plane[0].width, rot_info->plane[0].height, size);
> 
> Hm given how chatty KMS log level is this one wasn't that harmful
> but OK. Use to save me looking in debugfs/i915_gem_framebuffer and
> eyeball the VMA list. Granted that is much more manageable now after
> you added the human readable output there.

It's just the odd one out. If it is useful here, it presumably has some
use on the other branches - and do we want it at page allocation time or
vma creation. And I don't think we really want one at vma create, so I'd
prefer to improve the debugfs (or other) probe.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list