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

[Zhigang Gong]

> -----Original Message-----
> From:
> glamor-bounces+zhigang.gong=linux.intel.com at lists.freedesktop.org
> [mailto:glamor-bounces+zhigang.gong=linux.intel.com at lists.freedesktop.o
> rg] On Behalf Of Chris Wilson
> Sent: Saturday, January 21, 2012 1:55 AM
> To: zhigang gong
> Cc: zhigang.gong at linux.intel.com; glamor at lists.freedesktop.org
> Subject: Re: [Glamor] [PATCH 05/15] glamor_fbo: Introduce glamor fbo to
> manage all the fb/tex.
> 
> 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
> 
Thanks for your kindly testing.
> 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.
Ah, you hit another bug at fbo-pool branch. Mesa doesn't support load a A1
texture,
and this branch just removed the depth checking condition before upload
a pixmap to texture. If I put the condition back, then it will goto fallback
path
and is definitely still very slow. 

As I will start the long Chinese New Year holiday from today, I will add the
A1
texture uploading optimization support after I'm back, that's should not be 
very difficult.

Today, I will fix those the fls problem and has_gem detection method, just
check
the driver name is indeed not the best way. And of course will fix this A1
rendering
bug and although it's very slow. Then I will push this branch to Master
branch. This
will be the last thing I will do before I back from the vacation.

> -Chris
> 
> --
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> Glamor mailing list
> Glamor at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/glamor