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

[zhigang gong]

On Sat, Jan 21, 2012 at 1:54 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Fri, 20 Jan 2012 15:05:18 +0000, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> 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?
>
> old: glamor-no-fbo
> new: glamor-fbo
> Speedups
> ========
>  xlib             grads-heat-map  127331.39 -> 1449.00: 87.88x speedup
>  xlib              midori-zoomed  4566.85 -> 1534.30:  2.98x speedup
>  xlib                  evolution  3216.08 -> 2684.38:  1.20x speedup
>  xlib                       gvim  9429.61 -> 7945.96:  1.19x speedup
>  xlib         swfdec-giant-steps  4499.96 -> 3951.73:  1.14x speedup
>  xlib         gnome-terminal-vim  25417.66 -> 22459.87:  1.13x speedup
>  xlib          xfce4-terminal-a1  2659.70 -> 2350.43:  1.13x speedup
>  xlib       firefox-planet-gnome  11177.70 -> 9903.54:  1.13x speedup
>  xlib          firefox-talos-gfx  17092.11 -> 15309.88:  1.12x speedup
>  xlib                    poppler  10233.00 -> 9259.71:  1.11x speedup
>  xlib           firefox-fishbowl  39253.61 -> 35797.03:  1.10x speedup
>  xlib             poppler-reseau  2544.44 -> 2401.40:  1.06x speedup
>
> No slowdowns.  It looks like mesa could also benefit from some tuning of
> its allocator. The grads-heat-map result is most surprising, before the
> fbo-pool it is running at 75% cpu utilisation, so where it found the
> performance from I don't know. Ah, it is too good to be true, it's not
> rendering a1 surfaces at all.
> -Chris

I switched to use fls rather than ffs, and it suprised me, here is the result on
my machine,

ffs-256  means order = ffs(size/s56)

firefox-planet-gnome
fls-256: 10.3s
ffs-256: 9.3s
fls-32:    9.4s
ffs-32:    9.2s

The memory usage seems similar to each other, and I always set the max
expire count
to100. It's not very easy to understand. For now, I just keep the
fls-32 as my master
branch.  May need more investigation on the cache bucket allocation.

>
> --
> Chris Wilson, Intel Open Source Technology Centre