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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel