CVS Update: xc (branch: trunk)
eta at lclark.edu
Sun Oct 9 17:23:05 PDT 2005
On Mon, 2005-10-10 at 08:08 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2005-10-08 at 19:03 -0700, Eric Anholt wrote:
> > CVSROOT: /cvs/xorg
> > Module name: xc
> > Changes by: anholt at gabe.freedesktop.org 05/10/08 19:03:23
> > Log message:
> > Don't try the accelerated glyphs path for component-alpha text (which
> > I don't expect drivers to be able to accelerate without exa assistance).
> > Instead, drop back to plain old miGlyphs for a 62.5% +/- 1.5% reduction
> > in runtime of my ls -lR test (n=5) with component alpha. While a
> > reasonable approach would seem to be making a better test to see whether
> > the entire path would be accelerated and force migration appropriately,
> > my attempt at this made the situation much worse.
> What about having the driver expose a set of flags for triggering such
> behaviour ? The driver knows what it can do or can't (and might even do
> some kind of quick bench at startup) and set "hints" flags that can then
> influence EXA policy.
Right now I don't expect any driver to do component alpha text. So I
don't see the point in adding a flag before we make exa help drivers get
this done (and at that point, we could remove the check from the commit
in question). The patch I was working on would have been a small step
towards being able to do a CA helper (it added functions to pin pixmaps,
which we would need in order to do this), but I couldn't get it to make
this same improvement to text performance for some reason.
As far as the general idea of adding flags for things, CheckComposite
deals with the problem whether composite stuff will be accelerated. Want
to know if a particular thing will be accelerated? Just ask (only cost
is creation of the picture that you would have had to do to accelerate
anyway). As far as migration, I think we should make the migration in
general smarter before we go trying to add hacks to deal with particular
Eric Anholt eta at lclark.edu
http://people.freebsd.org/~anholt/ anholt at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 187 bytes
Desc: This is a digitally signed message part
More information about the xorg