Is XAA still supported in recent and future xserver?
Michel Dänzer
michel at daenzer.net
Tue Sep 14 02:49:47 PDT 2010
On Mon, 2010-09-13 at 18:55 -0400, Michael wrote:
>
> On Sep 13, 2010, at 6:41 PM, Matt Dew wrote:
>
> > I'm not necessarily arguing for dumping XAA (I don't know enough for
> > that, hence my questions.). I'm just from the school of thought that
> > if two things are redundant, get rid of one of them. Less maintenance,
> > confusion, duplicated effort, ... If EXA could be made to be
> > performant on that hardware, I think getting rid of XAA would be a
> > good idea, for the pre-mentioned reasons. If it can't, then end of
> > discussion for me.
>
> This would be a hell of a lot easier if EXA had an optional XAA-like
> VRAM allocator which doesn't insist on variable strides. With that
> alone converting most drivers would be almost trivial.
With the CreatePixmap2 hook used by the EXA "mixed" and "driver"
schemes, the driver can allocate the GPU accessible pixmap memory
however it pleases. To avoid code duplication between drivers, you could
create utility functions which can be used by the drivers for different
styles of memory allocation (Along those lines, it should be possible to
re-implement the "classic" scheme on top of the "mixed" scheme, which
might be a nice cleanup).
> > How does Gallium3D and cairo fall into this argument? Are they
> > alternatives to XAA and EXA? (again, I'm still learning.)
Cairo is probably not really suitable for this.
Gallium3D is a generic, shader-centric acceleration framework which can
already provide acceleration in the X server via a so-called 'state
tracker' which hooks into EXA. However, in the long term it would
probably be better to write a new state tracker which instead takes a
similar role as EXA or XAA, i.e. translates directly between the Xorg
DDX and the Gallium3D pipe driver. But again, given that Gallium3D
requires a shaderful 3D engine, this probably couldn't fully replace
EXA or XAA either.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
More information about the xorg-devel
mailing list