Is XAA still supported in recent and future xserver?

[Michel Dänzer]

On Die, 2010-09-14 at 12:39 +0300, Mart Raudsepp wrote: 
> 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:
> > >
> > > 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.

The driver can already achieve this using the "mixed" scheme. The
driver's PrepareAccess hook can decide if it wants the CPU to access the
pixmap contents in the GPU accessible memory directly or if they should
be migrated to 'normal' system memory first.


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