Performance of XRenderCompositeTrapezoids in the aliased case

[Michel Dänzer]

On Tue, 2009-02-03 at 04:10 +0200, Mart Raudsepp wrote:
> On Mon, 2009-02-02 at 21:28 +0100, Rémi Cardona wrote:
> > Le 02/02/2009 19:52, Clemens Eisserer a écrit :
> > > 2.) What do you think about a data structure where EXA drivers could
> > > tell EXA which features they support.
> > > This way EXA could e.g. choose to use A8 instead of A1 only when it
> > > really needed?
> > > This could help in various cases to decide which route to go.
> > 
> > I think Geode users would love to see this since the HW doesn't even do 
> > A8 but only ARGB32, and for them, the glyph cache was major regression 
> > since it uses a lot of A8 pixmaps.
> 
> Yeah, it might make sense to have such a way to signal common EXA code
> of what surface types are supported in hardware and perhaps some other
> features or limitations.

There's already driver flags which could be extended. However, I'm not
sure that's even necessary in this particular case; the EXA core might
be able to find out if the driver supports rendering to A8 simply by
calling the CheckComposite driver hook during startup.


> I shamefully admit I haven't actually gotten around to pinpoint this
> glyph perf regression with 101% certainty at Pict_A8 OpAdd's, but
> logically that should be the case.

Yeah, it's likely; it's the key part which provides most of the cache
speedup, so if it can't be accelerated, the glyph cache is degraded to
mostly overhead.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer