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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
