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