[Glamor] [PATCH 05/15] glamor_fbo: Introduce glamor fbo to manage all the fb/tex.

[Chris Wilson]

On Fri, 20 Jan 2012 22:51:54 +0800, zhigang gong <zhigang.gong at gmail.com> wrote:
> On Fri, Jan 20, 2012 at 10:08 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Fri, 20 Jan 2012 16:52:03 +0800, zhigang.gong at linux.intel.com wrote:
> >> From: Zhigang Gong <zhigang.gong at linux.intel.com>
> >>
> >> This is the first patch to implement a fbo/tex pool mechanism which
> >> is like the sna's BO cache list. We firstly need to decopule the
> >> fbo/tex from each pixmap. The new glamor_pixmap_fbo data
> >> structure is for that purpose. It's somehow independent to each
> >> pixmap and can be reused latter by other pixmaps once it's detached
> >> from the current pixmap.
> >
> > I'd had to greatly curtail the maximum cache time in order to prevent
> I found a bug at the previous patchset which will always find exact size.
> and Already fix it and push to my private branch:
> git://people.freedesktop.org/~gongzg/glamor
> 
> Would you please have one try on your machine?

That does the trick. The caches are now being reused and memory growth
is much slower, and in line with the original size of the working set
and there is a hint of improvement for cairo...

I'm back to the your fbo-pool branch with just s/ffs/fls/ now.

Looking at why it was so painful shows that _mesa_update_fbo_texture()
does a walk over all framebuffers in order to invalidate any that used 
the texture whenever that textures changes. That's always going to be an
issue if the fbo cache grows too large. Mesa is likely to want a broader
use case than just glamor to justify a more elaborate data-structure to
track the back-references from texture to renderbuffer. Anyway with the
fix, it appears a moot point for the time being.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre