Performance of XRenderCompositeTrapezoids in the aliased case

[Mart Raudsepp]

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.
In this Geode case there are no A8 hardware surfaces at all, so I would
have went and somehow just made EXA glyph cache always use its ARGB
stuff and convert early for the cache (as caching stuff that will have
to be converted on each cache usage to ARGB for hw acceleration makes it
not really a cache, mmkay), but if EXA would know this globally, perhaps
there will be other places where knowledge of this (and other
limitations) would be useful for limited hardware - similar cases where
EXA could handle things better if it knew; or earlier fallback to
software, etc.

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. Anyhow, EXA knowing the limitations
sounds good to me, and could give some generic optimization
opportunities that could benefit all hardware with the same limitation
at once.


PS: Those Geode users - get your hands dirty and start contributing
again ;)



Regards,
Mart Raudsepp,