Is XAA still supported in recent and future xserver?

[Mart Raudsepp]

On Mon, 2010-09-13 at 17:19 -0400, Alex Deucher wrote:
> On Mon, Sep 13, 2010 at 3:47 PM, Matt Dew <matt at osource.org> wrote:
> > On Mon, Sep 13, 2010 at 1:17 PM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> >>> Date: Mon, 13 Sep 2010 22:09:29 +0300
> >>> From: Tiago Vignatti <tiago.vignatti at nokia.com>
> >>>
> >>> On Mon, Sep 13, 2010 at 05:26:34PM +0200, ext Alex Deucher wrote:
> >>> > On Mon, Sep 13, 2010 at 11:18 AM, Matt Dew <matt at osource.org> wrote:
> >>> > > Is that something that should go on a TODO (wish)list?  Move remaining
> >>> > > DDXs from XXA to EXA? Maybe improve those drivers' performance on EXA
> >>> > > first?
> >>> >
> >>> > I'm not sure it's worth the effort.  Much of the older hardware isn't
> >>> > even capable of EXA (lack of offset-based blitters for solid/copy and
> >>> > the lack of 3D engines for composite).  For hw that is, it's a lot of
> >>> > work for old hardware that hardly anyone one uses.  I suppose there
> >>> > are a few chips that are still used where it may make sense.  In many
> >>> > cases shadowfb is as fast or faster than the blitters on these old
> >>> > chips anyway. XAA is mostly sw rendering now anyway.
> >>>
> >>> so this means we could deprecate XAA from the server, and if one cares about
> >>> it we recommend to use old servers?
> >>
> >> No.  XAA does make a noticable difference on some hardware.
> >>
> >
> > Does anyone have a list of what hardware XAA outperforms EXA?  and possibly why?
> 
> Most modern desktops use fancy alpha blending composite stuff which in
> most cases require a 3D engine.  Chips without 3D engines or very
> limited 3D engines, end up falling back to software.  EXA tries to
> accelerate as much as possible, but for fallback, you often get lots
> of ping-ponging of buffers between system ram and vram as you
> transition between accelerated ops and software fallbacks.  Once that
> happens you lose.

It might be nice if EXA could be told that it may do pixman fallbacks
with source and destination inside vram, for the purpose of hardware
that has shared memory, but not quite like intel full UMA (the hardware
acceleration can still be done only inside reserved video memory area).
This might avoid a lot of ping-ponging on such hardware if that works
out, without writing separate pixman fallback handling inside the
drivers with some complications I am not qualified to cite yet.

> XAA tends to be faster because it has only very
> limited hooks for composite stuff, so mostly pixmaps stay in system
> ram (where software ops are cheap) until they are needed for display.

Could EXA be told to behave that way as well? I guess missing
implementations of some hooks or so?


Mart